DEV Community: Getinfo Toyou

Overcoming Decision Paralysis: Building a Zero-Signup Activity Engine with Vanilla JS

Getinfo Toyou — Mon, 06 Jul 2026 14:30:28 +0000

We have all experienced those moments where we have free time, open our phone or laptop, scroll through feeds for twenty minutes, and still feel completely bored. It is rarely a lack of available options—it is decision paralysis. When everything is accessible at once, choosing a single activity becomes surprisingly exhausting.

Why I Built It

I wanted to build a practical tool to solve this exact loop. Most modern web applications try to maximize user retention by keeping people glued to a feed. I wanted to build the opposite: an instant, friction-free tool that gives you a single, concrete idea—a quick creative challenge, a physical task, or a mini learning project—and helps you move on to doing something active.

Key requirements from day one were zero friction: no user accounts, no onboarding flows, no tracking cookies, and no paywalls. You open the page, press a button, and get a realistic activity idea immediately.

Tech Stack

To keep performance high and maintainability simple, I chose a minimal stack:

HTML5 & Vanilla CSS: Designed with custom properties for rapid dark mode switching, standard CSS Grid layouts, and subtle CSS transitions.
Vanilla JavaScript (ES6+): Pure client-side logic without full framework overhead, keeping the entire application bundle under 45KB.
Web Storage API: Utilized localStorage to save user preferences, custom activity history, and bookmark favorites without requiring a backend database.
Static Site Hosting: Deployed via static distribution for sub-second global page loads.

Technical Challenges

1. Preventing Duplicate Suggestions Without User Accounts

Without saving user profiles on a server database, ensuring users do not get the same activity twice in a short session required a client-side solution. I created a lightweight queue algorithm in JavaScript that maintains a rolling history buffer in localStorage. Each time a random suggestion is generated, the algorithm checks the buffer history, filters out recently presented IDs, and updates the queue dynamically.

2. Schema Design and Filtering Performance

A boredom cure is only effective if suggestions match a user's current situation (e.g., indoor vs. outdoor, solo vs. group, low effort vs. active). I structured the dataset using a clean JSON schema with category tags, difficulty markers, and estimated time commitments. Filtering these attributes in real time on the client side ensures instant UI updates without network latency.

3. Low-Latency Performance Optimization

When a user is bored, even a two-second load screen can cause them to abandon the site and go back to passive scrolling. By avoiding external UI libraries and heavy JavaScript runtimes, the initial load time is nearly instantaneous even on slow mobile networks.

Lessons Learned

Building this project reinforced an important lesson: not every web application needs a backend database, OAuth authentication, or a full frontend framework. Stripping away non-essential architecture often results in a faster, more reliable, and far more user-friendly tool.

Try It Out

If you ever find yourself stuck deciding what to do next, you can try the project live at BoredNoMore. It is completely free, instant, and requires no registration. I would love to hear any technical feedback or ideas for new activity categories you think should be added!

Building a Zero-Cost, High-Performance Runner Game for the Browser

Getinfo Toyou — Wed, 01 Jul 2026 14:30:40 +0000

Building a Zero-Cost, High-Performance Runner Game for the Browser

Modern gaming often comes with a hidden tax. Even when a game is labeled "free-to-play," you are usually greeted by multi-gigabyte downloads, intrusive registration forms, pay-to-win mechanics, or aggressive advertisements. As a developer and a casual gamer, I missed the simplicity of the early web: clicking a link and instantly playing a game.

That is why I built Echo Runner, a fast-paced browser runner game where you run, dodge obstacles, and chase high scores. It is completely free, runs directly in your browser, and requires no downloads or sign-ups. You can play it right now at https://echorunner.getinfotoyou.com.

Here is how I designed and engineered this game with a strict budget of zero dollars for both myself and the player.

The Goal: High Performance on a Free Tier

My primary challenge was infrastructure. I wanted to host the game without recurring server costs, meaning I had to rely on free static hosting. However, free hosting plans have limits on bandwidth. If the game assets were too large, a sudden surge in traffic would quickly exhaust my free tier allocation.

To solve this, I set a strict budget for the initial load size: under 100 KB total.

By avoiding heavy game engines like Unity or Phaser, I kept the codebase lean. I built the entire game engine using native HTML5 Canvas and vanilla JavaScript. By writing custom physics, collision detection, and rendering loops from scratch, I eliminated external dependencies. The entire production build—including code, styling, and sound effects—comes in at just under 75 KB.

Technical Challenges

1. Achieving 60 FPS with Canvas

Creating a smooth, responsive runner game requires consistent frame rates. Since the game is targeting mobile browsers alongside desktop, I had to optimize the render loop.

Instead of constantly recreating objects in memory (which triggers the JavaScript garbage collector and causes stuttering), I implemented an object pool pattern. Obstacles and background elements are recycled. When an obstacle moves off-screen, it is deactivated and placed back into the pool to be reused later. This keeps memory usage completely flat during gameplay.

2. Resolution-Independent Rendering

Browser games are played on everything from high-resolution desktop monitors to low-end smartphones. To handle this variability, I structured the game logic around a virtual resolution (e.g., 800x450). The game logic updates using these fixed coordinates, while the canvas scales dynamically to fit the viewport.

function resizeCanvas() {
  const scaleX = window.innerWidth / virtualWidth;
  const scaleY = window.innerHeight / virtualHeight;
  const scaleToFit = Math.min(scaleX, scaleY);

  canvas.width = virtualWidth * scaleToFit;
  canvas.height = virtualHeight * scaleToFit;
  context.scale(scaleToFit, scaleToFit);
}

This approach guarantees that the gameplay area remains consistent across devices, ensuring a fair challenge for all players regardless of their screen size.

The Tech Stack

Graphics & Logic: Vanilla HTML5 Canvas and JavaScript. No external rendering libraries.
Styling: Minimal, responsive CSS using modern flexbox to center the game canvas and style the UI menus.
Audio: Web Audio API to synthesize sound effects programmatically, eliminating the need to load external MP3 or WAV files.
Deployment: Static hosting via GitHub Pages, utilizing a global CDN to deliver the game assets instantly to users worldwide.

Lessons Learned

Building Echo Runner taught me that constraint breeds creativity. When you cannot rely on a pre-built engine to handle physics or rendering, you are forced to understand how these systems work under the hood.

Furthermore, optimizing for low bandwidth and hosting efficiency directly translates to a better user experience. Players do not have to wait for a loading screen or download an app from an app store. They just visit the site and start playing.

If you are looking for a quick distraction or want to see how the performance holds up, head over to https://echorunner.getinfotoyou.com and try to beat the high score. It won't cost you a thing.

I Built a Random Wheel Spinner and Learned That Simple Tools Are the Hardest to Get Right

Getinfo Toyou — Fri, 26 Jun 2026 16:48:42 +0000

The Itch I Needed to Scratch

Every few weeks, someone in a group chat would ask: "How do we decide?" Movie night. Who pays. Which game to play next. And every time, we'd spend more time arguing about how to decide than actually deciding.

I wanted something dead simple. Paste in some options, spin, done. But every tool I found either required an account, threw ads at you, or had so many settings you needed a tutorial. So I built SpinDecide — a free, no-login random wheel spinner that just works.

This post is about why "just works" is deceptively hard to build.

The Stack

I kept it deliberately lean:

Vanilla HTML, CSS, and JavaScript — no framework overhead
Canvas API for rendering and animating the wheel
CSS transitions for UI polish
Deployed as a static site — fast, cheap, no server costs

No React. No build pipeline. No dependencies to maintain. The goal was that anyone could open the source and understand it in under ten minutes.

The Technical Challenges (Yes, Even a Spinner Has Them)

1. Making the Spin Feel Real

A wheel that stops abruptly feels broken. A wheel that always decelerates the same way feels fake. Getting the easing curve right took more iteration than I expected.

I ended up using a custom cubic-bezier-style deceleration applied to the rotation delta per frame. The key insight: the perception of randomness matters as much as actual randomness. If the wheel always stops in roughly the same quadrant, users notice — even if the math is correct. I added a random offset to the final resting position so it never felt predictable.

2. Label Rendering on Canvas

Canvas text doesn't wrap. If someone adds a long option like "Hawaiian pizza (controversial but valid)", you either truncate it, shrink the font, or let it overflow the segment.

I implemented dynamic font sizing: measure the text width, compare it to the segment arc length at a given radius, and scale down if needed. It's not perfect for extreme edge cases, but it handles 95% of real-world inputs gracefully without any user intervention.

3. Segment Color Distribution

With fewer than 6 options, a fixed color palette works fine. With 20 options, you need to auto-generate colors that are visually distinct and don't accidentally repeat next to each other.

I went with HSL color generation — evenly distributed hue values with slight saturation/lightness variation. Adjacent segments get hues far apart on the wheel. Simple, and it looks good across all segment counts.

4. State Management Without a Framework

With no framework, managing app state — the list of options, spin history, current result — means discipline. I used a single appState object and explicit update functions. Boring, but it made debugging easy and the code readable six months later.

Lessons Learned

Simplicity is a product decision, not just a technical one. Every feature I considered adding (weighted options, saved wheels, user accounts) would have made the tool slightly more powerful and significantly more complicated. I cut most of them. The constraint made the product better.

Canvas is powerful but verbose. For a project like this it's the right call — no library weight, full control. But I wrote a lot of boilerplate I'd abstract into helpers on the next project.

Small tools still need good UX copy. The button says "Spin!" not "Submit" or "Randomize." The result shows up big and bold. These tiny decisions took real thought.

Deployment friction kills momentum. Static hosting meant I could push changes and see them live in seconds. That speed kept me motivated to iterate.

Try It

If you've got a group that can't decide on anything, or you're a teacher who needs a random name picker, or you're settling a debate the civilized way — give it a spin:

👉 spindecide.getinfotoyou.com

No account. No ads in your face. Just add your options and spin.

Wrapping Up

Building something simple taught me more about product thinking than any complex project has. When you strip away the features, what's left has to actually work — and work well. The wheel spins, a winner appears, someone loses the argument about pineapple on pizza.

That's the whole product. And getting that right took real effort.

If you're building small tools, I'd love to hear what you're working on in the comments.

Who Actually Uses ASCII Art in 2024? (And Why I Built a Browser Tool for Them)

Getinfo Toyou — Wed, 24 Jun 2026 14:31:33 +0000

The Niche That Kept Asking

I never planned to build an ASCII art generator. But after watching the same three groups of people repeatedly struggle with clunky desktop software or sketchy upload-your-image sites, I figured someone should just solve it properly. That someone ended up being me.

The result is Asciiartmaster — a free, browser-based converter that transforms images and text into customizable ASCII art without sending a single byte to a server.

Who Actually Benefits Most

Before I talk tech, let me be specific about who this tool is genuinely for, because it's not everyone.

Developers are probably the heaviest users. If you've ever wanted a text-based logo for your CLI tool's startup banner, a README header that doesn't need an image asset, or retro-styled output for a terminal app, you've probably cobbled something together with a Python script or an npm package. This replaces that workflow with something you can use in 30 seconds.

Digital artists working in demoscene aesthetics, pixel art adjacent spaces, or generative art often want to experiment with character-based rendering. Having a fast feedback loop in the browser matters here — you want to tweak density settings and character sets without rerunning a script.

Retro tech enthusiasts are the most enthusiastic users. These are the people setting up BBS emulators for fun, adding ANSI art to their dotfiles, or just deeply appreciating that terminals used to be the entire visual interface. They get it immediately.

The Technical Side

The core challenge was doing meaningful image processing entirely client-side, without a backend, without WebAssembly initially, and without the conversion feeling sluggish.

The approach uses the HTML5 Canvas API heavily. When you load an image, it gets drawn to an off-screen canvas, and then I sample pixel luminance values across a grid. Each cell maps to a character from a density string — traditionally something like .:-=+*#%@ ordered from least to most opaque. The character chosen for each grid cell depends on how bright that region of the image is.

The tricky part was getting the sampling grid right. Go too coarse and you lose detail. Go too fine and the output becomes unreadable noise. The solution was making the character density and output width configurable, letting users tune the balance for their specific image.

For text-to-ASCII (the big blocky letter mode), I used a different approach — mapping each letter to a pre-defined multi-line character pattern, then assembling them horizontally with proper baseline alignment. Sounds simple, but handling variable character widths and spacing without everything going jagged took more iteration than expected.

The stack is deliberately minimal: vanilla JavaScript, Canvas API, and CSS. No frameworks. No build step. The whole thing loads instantly because there's nothing to bundle.

The Privacy Decision Was Non-Negotiable

A lot of similar tools ask you to upload your image to their server. That's fine for stock photos, but people routinely want to convert screenshots, internal diagrams, or personal photos. Sending those to a third party for processing is a reasonable thing to want to avoid.

Doing everything in the browser eliminates that concern entirely. The image never leaves your machine. This wasn't a marketing angle I bolted on afterward — it was a constraint I set before writing the first line of code.

Lessons Learned

Browser APIs are more capable than you remember. Canvas-based image manipulation used to feel like a workaround. Now it feels like the right tool.

Configurability matters more than defaults. The first version had fixed output width and a single character set. Half the feedback I got was people wanting to control those things. The current version lets you adjust both, and the tool feels significantly more useful as a result.

"Simple" tools have non-obvious edge cases. Transparent PNG backgrounds, very dark images, very light images, images with thin line detail — each of these required specific handling to produce readable output.

Try It

If any of those three groups sound like you, Asciiartmaster is free, runs entirely in your browser, and takes about ten seconds to get your first result out.

If you're a developer and end up using it for a README or CLI banner, I'd genuinely like to see what you make with it.

Building a Lightweight Tech & Online Safety Guide for India's Next Billion Users

Getinfo Toyou — Mon, 22 Jun 2026 14:30:55 +0000

India's digital growth over the last decade has been rapid. Millions of people, from students in small towns to grandparents in cities, have gained access to the internet. However, this swift onboarding has created a significant gap: digital literacy hasn't grown at the same pace as digital access. Every day, people are targeted by UPI scams, fake job offers, phishing links, and AI-generated misinformation.

Most technology websites focus on hardware reviews, smartphone comparisons, or high-end developer news. There is a lack of simple, direct resources that focus on digital safety and foundational technology concepts for everyday users. That is why I built Tech, a platform designed to bridge this gap.

The Core Problem

When my own relatives started receiving fraudulent text messages mimicking bank alerts, I realized how vulnerable the average user is. They don't need to know the clock speed of the latest processor; they need to know how to spot a fake website or how to verify a UPI request.

With the sudden rise of artificial intelligence, there is also a mix of curiosity and fear. People want to use AI tools for learning and work, but they don't know where to start or how to navigate these platforms safely. The main goal of Tech is to provide clear, jargon-free explainers on AI tools, timely scam alerts, and relevant tech news that directly impacts daily life.

The Tech Stack and Architecture

To build a platform aimed at a wide audience across India, performance and accessibility were the primary technical goals. Many users access the web on budget smartphones with unstable 3G or 4G connections.

Here is the stack I chose:

Frontend: Next.js with static site generation (SSG). This ensures pages are pre-rendered and load almost instantly, even on poor connections.
Styling: Pure CSS with a mobile-first design pattern. I avoided heavy UI libraries to keep the bundle size as small as possible.
Content Management: Markdown-based files stored in the repository. This allows for quick edits and version control without the overhead of querying a database for every page load.
Hosting & CDN: Vercel combined with global edge caching to ensure low latency across different regions in India.

Technical Challenges

The biggest technical challenge was optimizing the page weight. Every kilobyte of Javascript deferred is a win for a user on a low-end device. I spent a significant amount of time audit-profiling the site, removing unnecessary dependencies, and lazy-loading non-critical resources.

Another challenge was designing a layout that remains highly readable on small, low-resolution screens. I implemented scalable typography using CSS container queries and custom properties, ensuring that text is legible even on older smartphone models.

Lessons Learned

Building this site taught me that technical complexity is not always the answer. When building for the next billion users, simplicity in both code and design is the most critical feature.

Performance is accessibility: If a safety warning page takes ten seconds to load on a slow connection, it fails its purpose. Speed is a functional requirement, not just a metric.
Jargon-free writing is hard: Translating complex terms like "phishing" or "generative adversarial networks" into straightforward terms requires deep understanding. The UX must support this simplicity.

Try it out

The website is fully live and open to everyone. You can explore the explainers and active alerts at https://tech.getinfotoyou.com.

If you have feedback on how to make the content more accessible, or if you want to suggest a topic that needs a simple explainer, I would love to hear your thoughts in the comments.

I Built an AI Text Detector from Scratch — Here's What I Learned About Doing It the Hard Way First

Getinfo Toyou — Fri, 19 Jun 2026 14:31:12 +0000

The Hard Way

Before I shipped Aidetector, I spent two weeks doing AI detection manually.

I'm not joking. A client asked me to review a batch of blog posts for AI-generated content, and I had no reliable free tool. So I did what any developer does when they're stubborn and slightly overconfident — I started reading papers.

I pulled research on AI writing patterns. I opened a spreadsheet. I flagged things like:

Sentence length variance (AI texts are suspiciously uniform)
Overuse of hedging language ("it is important to note that...")
Low lexical diversity in paragraph transitions
Predictable semantic structure — topic sentence, three supporting points, wrap-up

I was manually scoring documents on a 12-point rubric. It took me about 20 minutes per article. For 40 articles.

That's when I thought: this should be a tool.

Why I Built It

Most free AI detectors at the time were either:

Capped at 500 words (useless for long-form content)
Requiring signup or API keys
Running on a single heuristic with no transparency about what they were actually checking

I wanted something that ran entirely in the browser, explained its reasoning, supported recent models like GPT-5 and Claude 3.7, and had zero word limits. No backend. No user data. No nonsense.

The Tech Stack

The entire thing runs client-side:

Vanilla JavaScript — no framework overhead, just fast DOM manipulation
HTML/CSS — keeping it lightweight and accessible
No external APIs — everything is computed locally in the browser

The detection logic runs 12 linguistic pattern checks derived from published NLP research. These include:

- Burstiness score (variance in sentence lengths)
- Perplexity approximation (word predictability heuristics)
- Hedging phrase frequency
- Passive voice ratio
- Transition word overuse
- Semantic flatness (paragraph topic variance)
... and six more

Each check returns a weighted score. The final result is a composite confidence percentage, broken down so the user can actually see why the tool flagged something.

The Technical Challenges

1. Approximating perplexity without an LLM

True perplexity requires a language model to score token probabilities. I don't have a backend, so I approximated it using a trigram frequency lookup built from a curated corpus. It's not perfect, but it's directionally accurate for the patterns I care about.

2. Avoiding false positives on technical writing

Technical documentation naturally has low sentence variance and formal structure — exactly what my detector was flagging as AI. I had to add a context-aware exemption layer that detects domain-specific vocabulary density and adjusts scoring accordingly.

3. Keeping up with new models

GPT-5 and Claude 3.7 write noticeably differently than earlier models. I had to collect new sample sets and re-weight several heuristics. This is an ongoing calibration problem — the patterns shift as models improve.

Lessons Learned

Doing it the hard way first was actually useful. Building a manual rubric before automating it forced me to understand the problem domain deeply. I wasn't just wiring up someone else's API — I actually knew what I was detecting and why.

Transparency builds trust. Showing users which patterns triggered and why has been the most-praised feature. People don't want a black box percentage. They want to understand the reasoning.

No-login tools get used. Friction kills adoption. Removing signup entirely meant people actually came back and shared it.

Browser-only is a genuine constraint, not just a gimmick. You have to think carefully about what's computationally feasible without a server. Some things I wanted to add (real perplexity scoring, model fine-tuning) are simply not possible client-side at scale.

Try It

If you're an educator reviewing student submissions, a content editor checking freelance work, or just curious how your own writing scores — give it a shot: aidetector.getinfotoyou.com

No word limits. No login. No API key. Paste your text and see what it finds.

I'm still actively improving the heuristics. If you find a false positive or a miss, I'd genuinely like to know.

Automating 301 Redirects: How We Built a WordPress Plugin to Scan 404s and Map Clean URLs Using Gemini AI

Getinfo Toyou — Wed, 17 Jun 2026 14:30:26 +0000

If you run a WordPress site, you've probably faced the 404 headache. Maybe you migrated your content, updated your permalinks, or pruned old posts. Suddenly, search engines start reporting broken links, and your visitors hit dead ends.

While manual redirection plugins exist, they quickly become a chore when you are dealing with dozens or hundreds of broken URLs. That is why I built FixLinks: a WordPress plugin designed to scan your site's 404 errors and automatically suggest the most relevant 301 redirect targets using the Gemini API.

Who Benefits Most?

I built this tool with a few specific user profiles in mind:

The Long-Term Blogger & Content Publisher
If you have run a blog for five years, you have likely restructured your categories or updated older articles multiple times. Tracking down every dead link that external sites point to is nearly impossible. FixLinks helps you preserve the search engine authority (link equity) those old posts built up over time by finding the closest modern equivalent on your current site.
The SEO Consultant and Agency Manager
Managing SEO for clients means constantly looking at audit reports. Cleaning up 404 errors on a large ecommerce site or content hub is tedious work. Instead of manually mapping spreadsheet rows of old URLs to new ones, consultants can run a scan, review AI-generated suggestions, and approve them in bulk.
The Web Developer Handing Off Sites
When developers hand over a migrated site to a client, links often break post-launch. Rather than writing complex redirection rules in .htaccess or Nginx configs—which clients can easily break—developers can set up this plugin so clients can manage redirects themselves using a simple interface.

The Tech Stack

The architecture is split into two main components:

The WordPress Plugin (PHP & Javascript): A lightweight client that hooks into WordPress's template redirect engine to catch 404 events, logs them, and exposes a clean React-based admin dashboard.
The Redirect Matching Engine (Node.js & Gemini API): A serverless microservice that takes your active 404 path list, compares it against your public sitemap or published page index, and queries Gemini. We use the Gemini API's structured JSON output format to ensure we receive clean arrays of suggestions containing the source path, suggested destination, and a confidence score.

Technical Challenges

The biggest challenge was semantic matching without burning API tokens.

Simply sending every single 404 path to the LLM individually is slow and expensive. To solve this, we implemented a multi-tiered filtering system:

Sitemap Indexing: The plugin indexes all valid published URLs and keeps a lightweight local cache.
String Similarity Pre-filtering: We use a quick Jaro-Winkler distance calculation to handle simple typos or URL changes locally.
LLM Batching: If local heuristics fail to find a high-confidence match, the remaining paths are batched and sent to Gemini. The model is prompted to map ambiguous paths (e.g., /get-in-touch vs. /contact-us-now) by understanding the semantic intent behind the URL slugs.

Lessons Learned

One of the most important takeaways from building this was the necessity of a human-in-the-loop design.

In early prototypes, I experimented with fully automated redirects. If a 404 occurred, the plugin would automatically map and redirect the user on the fly. However, this occasionally created redirect loops or mapped irrelevant pages, leading to a confusing user experience. I quickly realized that AI should act as an assistant, not an autonomous driver. The current iteration presents the mapped suggestions in a dashboard, allowing the site owner to review and apply them with one click.

Try It Out

If you are tired of manually mapping broken links or looking to restore lost search rankings, you can find the plugin and try it out at https://fixlinks.getinfotoyou.com.

I'd love to hear your feedback on the matching accuracy and any features you would like to see added.

Simplifying Client Management: The Tech Stack and Architecture Behind a Clean WordPress Client Portal

Getinfo Toyou — Mon, 15 Jun 2026 14:30:32 +0000

Managing clients is often more challenging than the actual work itself. After trying several heavy project management suites and dedicated SaaS client portals, I noticed a recurring, frustrating pattern: clients rarely logged in. They found the dense dashboards overwhelming and confusing. I wanted to build something that lived directly on my own WordPress site, looked clean, and focused solely on what clients actually need: files, invoices, contracts, and a simple way to get quick answers. This is the story of how and why I built PortalWP, a client portal designed around simplicity.

Why I Built It: The Battle Against Dashboard Bloat

Most client portals attempt to do everything under the sun. They include complex Kanban boards, intricate support ticket systems, and endless nested chat threads. While this sounds good on paper, for a small agency or freelancer, it often creates friction. Clients just want to download a final deliverable, pay an invoice, or sign a contract. When the portal is too complex, they revert to email. I built PortalWP to strip away this unnecessary noise. The goal was to build a clean dashboard that takes less than two minutes for a client to understand and navigate successfully.

The Tech Stack: Bridging WordPress and React

To achieve a modern, responsive feel within the WordPress ecosystem, I chose a hybrid architecture:

WordPress Core & REST API: WordPress handles authentication, user roles, and database storage. Using the built-in custom post types and user meta kept the backend extremely lightweight and secure without needing external databases.
React: The client portal dashboard is built entirely with React, communicating with WordPress via custom REST API endpoints. This provides a single-page app experience without constant page refreshes, which is crucial for a smooth user experience.
Tailwind CSS: For styling, I used Tailwind to keep the design utility-first and ensure the interface looks modern and adapts to any screen size.
OpenAI API: I integrated a lightweight AI assistant to help clients search through shared documents and get quick answers based on the project files.

Technical Challenges: Security and Seamless Integration

Building this wasn't without its hurdles. Two main challenges stood out:

Secure File Handling: By default, files uploaded to WordPress are public if someone guesses the URL. For a client portal, files must remain private. I had to implement a custom routing system that stores files outside the public directory and serves them through secure, authenticated PHP streams.
Lightweight E-Signatures: Integrating e-signatures without relying on expensive third-party APIs was tricky. I built a canvas-based signature pad in React, converting the drawing into a secure image path, and bound it to a hash of the contract PDF to ensure document integrity.

Lessons Learned

The biggest lesson was that constraints breed better user experiences. In early builds, I wanted to add nested tasks and chat threads. However, feedback from early testers showed that adding tasks made the interface feel like 'work' to clients. Removing features and focusing on a clean files-and-invoices view was what actually drove client adoption. Keeping things simple is technically harder because you have to decide what not to build, but it pays off in user satisfaction.

Conclusion

Building PortalWP taught me that clients value clarity over features. If you are running an agency or freelancing, you can try out the portal at portalwp.getinfotoyou.com and see how simplifying your client interactions can save you hours of admin work.

Building a Strategic Endless Runner: How to Keep Mobile Game Architecture Simple

Getinfo Toyou — Fri, 12 Jun 2026 14:30:26 +0000

Mobile gaming often feels cluttered. Between heavy menus, daily log-ins, and complex combat mechanics, sometimes you just want a clean, simple game to play during a short break. I built Echo Runner to fill that gap. The goal was to take the classic, easy-to-learn mechanics of an endless runner and add one straightforward strategic twist: a 3-second ghost trail that follows you and clears obstacles. It’s intuitive from the first swipe, keeping the player experience focused and stress-free. The focus was entirely on getting a player from the app launch into the game in under three seconds.

The Tech Stack

I chose Unity and C# for this project. Unity is well-suited for lightweight mobile games, and its rendering pipeline allowed me to design clean, minimalistic assets that load quickly. To ensure the game runs smoothly, I stuck to a simple, unlit 2D art style that doesn't tax the mobile GPU. For the leaderboard and player stats, I avoided massive backend frameworks that require complex authentication. Instead, I used a lightweight REST API that interacts with a simple SQL database. This keeps the network overhead extremely low and ensures that even on spotty mobile connections, players can upload their scores without lag.

Technical Challenges: Tracking the Trail

The core mechanic is the ghost trail. Initially, I thought about recording the player's exact physics inputs and replaying them, but that quickly became a nightmare of desynchronization and performance drops on older Android devices.

To solve this simply and keep the game running smoothly at 60 FPS, I implemented a simple queue-based system. Every frame, the game records the player's position and rotation into a fixed-size ring buffer (storing exactly 3 seconds worth of coordinate data). The ghost trail object simply reads from the head of this buffer.

Here is a simplified look at the implementation:

// Simplified ring buffer logic for trail tracking
public class TrailTracker : MonoBehaviour 
{
    private Queue<Vector3> positionQueue = new Queue<Vector3>();
    public int targetFrameCount = 180; // 3 seconds at 60 FPS

    void Update()
    {
        positionQueue.Enqueue(transform.position);
        if (positionQueue.Count > targetFrameCount)
        { 
            Vector3 trailPosition = positionQueue.Dequeue();
            UpdateGhostPosition(trailPosition);
        }
    }
}

This approach kept memory allocation almost at zero during gameplay, preventing the garbage collector from causing annoying frame stutters on budget phones. Using a simple data structure rather than complex physics simulation saved weeks of debugging.

Keeping the UX Clean

Another area where I focused on simplicity was the user interface. Many games overwhelm players with pop-ups, store offers, and multi-tier upgrade menus. I wanted to build something cleaner. There are no nested menus or loading screens. You open the app, press play, and you're in. The controls use simple swipe gestures that map directly to player lane changes. The ghost trail handles obstacle collision automatically, meaning players don't have to learn complex button inputs. They just run, swipe, and let their past actions clear their path.

Lessons Learned

Simple architectures survive changes. By avoiding complex physics simulations for the ghost trail, implementing new power-ups and skins later was incredibly easy.
Polish the core loop first. Spend time on the swipe responsiveness rather than adding dozens of features. If the basic movement feels good, the game is fun.

Try It Out

Echo Runner shows that you don't need complex systems to make an engaging mobile game. By keeping the code modular and the mechanics simple, I built a game that is easy to jump into and runs smoothly on almost any device.

You can try Echo Runner for free on Google Play: Echo Runner on Google Play Store. Let me know what you think of the trail mechanic!

Building a Frictionless Markdown and HTML Converter for Android

Getinfo Toyou — Wed, 10 Jun 2026 14:30:21 +0000

The Problem with AI-Generated Output on Mobile

If you use LLMs to draft articles, outline code, or generate copy on your phone, you have probably run into the formatting bottleneck. You prompt an AI, it spits out a block of mixed markdown, raw text, and nested HTML, and then you have to figure out how to clean it up.

On a desktop, this is a minor inconvenience. On a mobile device, copying, pasting, and manually replacing tags or asterisks is frustrating. I built AIMarkdownPro Editor to solve this specific problem, focusing entirely on speed and simplicity.

Why I Built It

I draft a lot of my thoughts, documentation, and blog outlines on my phone during commutes. When using AI assistants to help structure these thoughts, the output is rarely ready for publishing. I found myself jumping between notes apps, web-based converters, and text editors just to get clean Markdown or HTML.

I wanted a dedicated tool that did one thing really well: accept messy text, parse it instantly, and let me convert it back and forth between Markdown and HTML without any fuss.

The Simplicity-First Design

The core design goal was zero friction. Many mobile text editors try to be full IDEs or desktop replacements, cluttering the small screen with nested menus, custom keyboards, and complex file managers.

For this app, the user experience is straightforward:

Paste your text.
Tap to toggle between Markdown and HTML.
Preview in real-time.
Copy the clean code or share it directly to your target application.

By keeping the interface minimal, the app feels fast and lightweight, allowing you to format your text and get back to your workflow in seconds.

Under the Hood: The Tech Stack

I chose native Android development using Kotlin and Jetpack Compose. Jetpack Compose was a natural fit for this project because of its declarative nature.

UI State Management: Compose allowed me to bind the editor text state directly to the parser. When you type or paste, the state updates, triggering the background parsing engine, and updates the preview seamlessly.
Parsing Engine: For converting Markdown to HTML, I used a lightweight Java-based markdown parser. The real challenge was the reverse: parsing HTML back into readable Markdown. I implemented a custom AST (Abstract Syntax Tree) converter that processes HTML nodes and translates them into clean Markdown syntax without adding unnecessary line breaks or artifact characters.
Web Fetcher: The app also includes a simple feature to fetch web pages directly. It extracts the main content block from a URL and converts it straight to Markdown, stripping out ads, navigation headers, and scripts.

Overcoming Technical Challenges

The primary technical challenge was managing performance during real-time rendering. Parsing large blocks of text on every keystroke can cause typing lag on budget Android devices.

To keep the editor responsive, I offloaded the parsing logic to Kotlin Coroutines. The parser runs on a background thread (Dispatchers.Default), while a debouncing mechanism ensures we only trigger the parse job after a short pause in typing. This keeps the main thread free and the editor interface smooth.

Handling edge cases in bidirectional conversion was another hurdle. Nested tables, mixed inline styles, and unclosed HTML tags from incomplete AI outputs frequently broke standard parsers. I had to build robust fallback rules in the parser to gracefully handle and clean up malformed code.

What I Learned

Building this app taught me that stripping away features is often harder than adding them. I initially planned to add cloud syncing, folder management, and custom themes. However, testing showed that these additions only distracted from the core utility: fast, painless text cleaning. Staying focused on the primary problem allowed me to ship a tool that actually gets used daily.

Try It Out

If you frequently work with formatted text on Android, you can try the app yourself on Google Play.

For more lightweight utilities and projects, feel free to check out my portfolio at getinfotoyou.com.

Why I Built a One-Time Purchase JavaScript Course App in a Subscription World

Getinfo Toyou — Fri, 05 Jun 2026 14:30:54 +0000

Let's face it: the current landscape of mobile coding education can be deeply frustrating. If you want to learn JavaScript on your phone during your daily commute, you are usually forced to choose between two highly compromised options. You either download a "free" app that interrupts your learning flow with unskippable 30-second video ads every three minutes, or you get pushed into a $25-a-month subscription model that slowly drains your wallet.

I wanted a third option. I believe that mastering the fundamentals of programming—things like modern ES6+ syntax, DOM manipulation, and asynchronous logic—requires deep, unbroken focus. Distractions ruin that focus. I wanted to create a premium, distraction-free environment where you pay once and own the material forever. That is exactly why I built the Learn JavaScript Pro Course app for Android.

Going Against the Grain: The One-Time Purchase

When designing this app, I specifically wanted to focus on what makes it different from the heavy-hitting paid alternatives on the market. Most premium coding platforms today are either expensive web-based bootcamps or subscription-based services that lock you into monthly recurring revenue models.

I decided to take a different approach. Learn JavaScript Pro is a single, lifetime purchase. There are no recurring fees, no hidden "gems" or in-app currencies required to unlock the next chapter, and absolutely zero ads. Furthermore, the entire curriculum is available completely offline. Whether you are on a subway, an airplane, or just trying to disconnect from the internet to study, the content is always accessible.

The Tech Stack

Since I was building an app to teach JavaScript, it only felt right to build it using JavaScript. I chose React Native (via Expo) as my core framework.

For local data persistence—tracking exactly which modules you have completed and saving your quiz scores—I opted for WatermelonDB. It operates over SQLite, is incredibly fast, and is perfectly suited for a fully offline-first experience. The course content itself is authored entirely in Markdown. I integrated a custom parser to render syntax-highlighted code blocks natively within the mobile UI, ensuring the code looks exactly like it would in a modern IDE.

Technical Challenges

Building an offline-first educational app came with a unique set of hurdles:

1. Native Code Rendering: Rendering raw text on a phone is simple, but rendering properly formatted, scrollable code blocks with accurate syntax highlighting on a narrow 6-inch screen was a massive headache. I had to build a custom rendering pipeline that parsed my Markdown files and mapped code fences to a React Native ScrollView containing stylized text nodes. Ensuring that horizontal scrolling felt natural without breaking the vertical scroll of the main article took days of tweaking.

2. State Management for Offline-First: Ensuring that a user's progress is saved instantly without relying on a cloud database meant rethinking how I handled state. Managing local database migrations was particularly stressful. If I push an app update to the Play Store with new curriculum modules, I have to ensure the local SQLite database updates its schema without a single user losing their hard-earned progress.

Lessons Learned

The biggest lesson I took away from this project wasn't actually technical; it was pedagogical. You cannot simply copy and paste a web-based coding tutorial onto a mobile screen. Long paragraphs and 50-line code snippets are terrible for mobile learning.

I had to heavily refactor my entire curriculum to utilize "micro-learning" principles. I broke complex topics into short, punchy explanations followed by small, highly focused code examples. It forced me to become a more concise writer and a better teacher.

Conclusion

Building a one-time purchase app in an industry obsessed with monthly subscriptions feels a bit risky as a solo developer. But my goal at getinfotoyou.com is to build tools that respect the user's time and focus.

If you are an aspiring web developer or a self-taught coder looking for a clean, focused way to learn modern JS without the noise and the endless fees, I invite you to check it out.

You can find the Learn JavaScript Pro Course on Google Play. I would love to hear your feedback on the offline experience!

Building an Anonymous Safe Space for Developers (And Why I'm Keeping It Free)

Getinfo Toyou — Mon, 01 Jun 2026 14:30:49 +0000

If you've spent any significant amount of time in software engineering, you know that the reality of the job rarely matches the polished open-source projects or flawless tutorials we see online. Behind every clean architecture diagram, there’s usually a duct-taped legacy system, a developer battling imposter syndrome, or a hidden bug that someone accidentally shipped to production on a Friday.

We all have these stories, but there aren't many places to share them without worrying about professional repercussions or tying them back to our GitHub profiles. That’s exactly why I built DevConfessions: Code Secrets — an Android app designed as a completely anonymous platform for developers to share their workplace stories, coding secrets, and career struggles.

And perhaps most importantly, I decided to make it entirely free to use. Here's a look at why I built it, how it came together, and what I learned along the way.

Why I Built It

The idea came after a particularly stressful week of debugging a monolithic codebase. I realized how isolating it can feel when you think you're the only one struggling with spaghetti code or feeling overwhelmed by unrealistic sprint goals.

I wanted to create a judgment-free zone. A place where someone could confess, "I still don't really understand Webpack, I just copy-paste configs," or "I accidentally dropped the staging database and blamed it on a network blip," and receive empathy instead of criticism. I wanted to build a community grounded in the messy reality of tech careers.

The Tech Stack

To keep the development process agile and maintainable as a solo developer, I opted for a modern Android stack:

Language: Kotlin
UI Framework: Jetpack Compose (because building declarative UIs is just more enjoyable)
Architecture: MVVM (Model-View-ViewModel) for clean separation of concerns
Backend/Database: Firebase (Authentication for anonymous sessions, Firestore for real-time syncing of confessions)
Dependency Injection: Hilt

Technical Challenges

Building a platform centered around anonymity presents a few unique challenges.

First, handling authentication without asking for user data. I utilized Firebase Anonymous Authentication, which ties an account to the physical device rather than an email or phone number. This ensures users can keep their session and history without ever handing over personal information.

Second, content moderation is tricky when everything is anonymous. I had to implement a robust reporting system and basic automated filtering to ensure the platform remains a safe space for venting and humor, rather than devolving into toxicity. Balancing free speech with community safety is an ongoing learning process.

Lessons Learned

One of the biggest takeaways from this project was the power of simplicity. When you strip away profiles, follower counts, and avatars, the focus shifts entirely to the content and the shared experience.

From a technical standpoint, adopting Jetpack Compose significantly sped up my iteration time. It allowed me to focus more on the user experience—making sure the app felt smooth and responsive—rather than wrestling with XML layouts.

Why It's Free

When I launched DevConfessions, I had a choice to make about monetization. I could have added premium tiers, restricted the number of confessions you could read per day, or put the best stories behind a paywall.

But that defeated the entire purpose of the app.

The goal was to build a supportive community, and putting up financial barriers didn't align with that. Software engineering is already a field with enough gatekeeping. Whether you're a senior architect or a bootcamp graduate looking for your first role, everyone deserves access to a space where they can see that they aren't alone in their struggles. So, the app is completely free to download and free to use. No hidden subscriptions, no gated features. Just a straightforward place to read and share.

Wrapping Up

Building DevConfessions has been a rewarding side project, not just technically, but in seeing the kind of honest, relatable stories that engineers share when the pressure of public identity is removed.

If you want to read some relatable workplace stories, drop a confession of your own, or just realize that nobody else knows what they're doing either, you can download DevConfessions on Google Play.

Have you ever worked on a project focused on anonymity? I'd love to hear about the technical choices you made in the comments.