DEV Community: Getinfo Toyou

Stop Paying for Token Optimization: Building a Free JSON to TOON Converter

Getinfo Toyou — Fri, 08 May 2026 14:32:23 +0000

Ever noticed how quickly your AI API bills pile up when sending heavily nested JSON payloads? A few months ago, I was working on a project that required passing complex, structured data to an LLM. The token usage was unexpectedly high, and after analyzing the request logs, the primary culprit was obvious: the standard JSON format itself. All those repetitive quotes, curly braces, colons, and whitespace characters were eating into my context window and artificially inflating my API budget.

That's when I began investigating TOON—a more compact data representation format that strips away the structural bloat of JSON while retaining the underlying relationships in the data. However, the ecosystem around it surprised me. The reliable tools available for converting JSON to TOON were often hidden behind enterprise SaaS paywalls, bundled into expensive developer suites, or offered free tiers with aggressively strict usage limits. As a solo developer at getinfotoyou.com, I didn't want to add yet another monthly subscription just to optimize my API calls.

So, I decided to build JSONtoTOON. It is a completely free utility that converts your standard JSON data into the TOON format, reliably reducing payload sizes by 40-60%. You can try it out here: https://json-to-toon.getinfotoyou.com.

Why I Built It (and Kept It Free)

When you are optimizing prompts and building AI-driven features, every single token matters. A significant number of developers are turning to paid solutions to minify their payloads, monitor their usage, or convert data into more efficient formats. While those premium tools certainly offer value, I firmly believe that fundamental optimization utilities—especially something as straightforward as format conversion—should be accessible to the entire community.

I built JSONtoTOON primarily to solve my own optimization bottleneck, but I designed it to stand apart from the paid alternatives. I wanted it to be entirely client-side, incredibly fast, and free of any artificial constraints. There are no API limits, no accounts required to save your work, and no credit cards needed. It operates as a straightforward, single-purpose tool for developers who want to reduce their AI token costs immediately.

Technical Challenges

The core challenge of building this wasn't merely converting the data from one format to another; it was ensuring the conversion was completely reliable and that the resulting output remained semantically identical for an LLM to process correctly.

Handling deeply nested JSON arrays, complex object hierarchies, and mixed data types required a robust parsing strategy. I initially ran into issues with specific edge cases—like properly escaping strings that contained TOON-specific delimiters, or deciding how to handle null values and empty arrays consistently without confusing the AI model downstream.

Another significant hurdle was performance. Since my goal was to keep the tool free by avoiding server-side processing costs, the conversion logic had to run entirely in the browser. It needed to be efficient enough not to freeze the UI, even when a user pasted in a massive JSON file containing tens of thousands of lines of data.

The Tech Stack

To keep the application fast and maintainable, I kept the stack lean:

Frontend UI: Vanilla JavaScript paired with clean, custom HTML and CSS. I wanted to avoid the overhead of heavy JavaScript frameworks to ensure the application loads instantly on any device.
Parsing Logic: I wrote a custom JavaScript parser optimized specifically for speed and memory efficiency during the conversion process.
Hosting Strategy: The entire application is deployed statically. This keeps server overhead virtually non-existent, ensuring high availability and allowing me to keep the tool free forever.

Lessons Learned

Building this utility taught me a great deal about browser performance boundaries and the intricacies of data serialization. One of the most important takeaways was the necessity of web workers. When I first implemented the parsing logic for large files, the synchronous execution blocked the main thread, causing the browser to stutter. Moving that heavy lifting to a background worker made the user experience feel seamless, regardless of the file size.

I also learned that modern LLMs are surprisingly adaptable. When testing the TOON outputs, the models consistently parsed the compressed data just as accurately as the original JSON. It confirmed my hypothesis that significant token savings do not have to come at the cost of model comprehension.

Conclusion

Optimizing your AI development workflows shouldn't require an expensive, recurring subscription. If you are building applications that rely heavily on LLM APIs and want to stretch your budget further, I highly recommend looking into data format optimization.

Give JSONtoTOON a try for your next project. It is a simple, effective, and completely free way to cut down on your payload size and keep your API costs manageable.

You can check it out here: https://json-to-toon.getinfotoyou.com. Let me know in the comments if it helps optimize your token usage, or if there are any specific edge cases in your JSON data that I should support!

Building a 100% Free, Client-Side Image Converter for Web Developers

Getinfo Toyou — Wed, 06 May 2026 11:17:15 +0000

As web developers and designers, we deal with images constantly. Optimizing those images—converting them to modern, lightweight formats like WebP or AVIF, and resizing them to fit responsive layouts—is an everyday task. Yet, I found myself constantly frustrated by the available online tools.

Most "free" image converters aren't actually free. They lure you in, only to hit you with arbitrary file size limits, daily usage caps, or watermarks. If you want the real features, you have to shell out for a monthly subscription. On top of that, many of these services require you to upload your sensitive client assets to their servers to process them, which is a massive privacy concern.

I decided enough was enough. I wanted a tool that was actually free, genuinely respected privacy, and did exactly what it said on the tin. That's why I built Photoconvert, a secure, in-browser tool to resize and convert images. And yes, it is completely free, with no strings attached.

Why Build Another Image Converter?

The primary motivation was value and accessibility. There is no reason a developer should have to pay a recurring fee just to convert a PNG to a WebP. The computing power required to do this already exists on your machine.

By moving the processing from a remote server to the client's browser, the operational costs of running the application drop to near zero. I don't have to pay for expensive cloud compute instances to crunch pixels. Because my server costs are negligible, I can pass those savings directly to the user—meaning the tool can remain genuinely free forever, without needing to artificially gate features behind a paywall.

The Technical Approach

To achieve this, the entire application had to be client-side. The tech stack relies heavily on modern browser APIs rather than a traditional backend architecture.

The Stack:

HTML5 Canvas API: For resizing and manipulating the image data directly in the browser.
Modern JavaScript: For orchestrating the file reading, conversion logic, and user interface.
Web Workers: Essential for keeping the UI responsive.
WebAssembly (WASM): While the Canvas API handles a lot natively, supporting newer, complex formats like AVIF purely in the browser often requires leveraging WASM ports of existing C/C++ libraries to ensure broad compatibility and performance.

The Challenges of Client-Side Processing

Building an app that processes media entirely in the browser isn't without its hurdles. When you rely on the user's device, you give up control over the execution environment.

Memory Management: Browsers have strict limits on how much memory a single tab can consume. When a user drops a massive, high-resolution TIFF file into the application, decoding that image into raw pixel data can easily spike memory usage and crash the tab. I had to implement careful garbage collection and ensure memory was explicitly freed up after each conversion.
Performance Bottlenecks: JavaScript is single-threaded. Running intense image processing on the main thread will freeze the UI, leading to a terrible user experience. Offloading the heavy lifting to Web Workers was essential to keep the interface responsive while the pixels were being crunched in the background.
Format Support: Browsers are notoriously inconsistent with what image formats they can encode and decode natively. While most can handle JPEG and PNG, encoding a WebP or AVIF on older browsers required careful feature detection and fallback strategies.
Handling Metadata: Handling color profiles and preserving EXIF data across different formats also proved tricky when relying purely on client-side APIs, requiring careful manipulation of the binary file headers before writing the final output.

Lessons Learned

Building Photoconvert reinforced a key lesson: the modern web browser is a remarkably capable operating system in its own right. We often default to spinning up Node or Python servers for tasks that the client's machine could easily handle.

By leaning into client-side processing, not only do we protect user privacy—because the files literally never leave their device—but we also create a more sustainable and cost-effective application model. It's a win-win. Users get a fast, free, and secure tool, and the developer isn't burdened with scaling costly server infrastructure. This project also highlighted the importance of progressive enhancement. Ensuring the core functionality works gracefully even on lower-powered devices, while offering faster WebAssembly-backed conversions on modern setups, provides a balanced experience for everyone.

Try It Out

If you're tired of hitting paywalls just to optimize an image for your latest project, give it a spin. It's designed to be a quick, reliable utility in your web development toolkit.

You can try it here: Photoconvert

Drop a file in, convert it to WebP or AVIF, and see the in-browser processing in action. No accounts, no subscriptions, just free image optimization. Let me know what you think or if there are specific formats you'd like to see supported next!

Building a Financial Tool: The Math and Logic Behind a Home Loan EMI Calculator

Getinfo Toyou — Mon, 04 May 2026 13:28:15 +0000

Introduction

Have you ever stared at a bank's home loan sheet and wondered how exactly they arrived at those numbers? That was me a few months ago. I was exploring real estate options, and every bank had its own proprietary calculator. I wanted to see the raw numbers, understand the reducing balance method, and visualize the long-term impact of a loan without navigating through heavy, ad-ridden financial portals or providing my email address to a lead-generation form.

So, I did what developers usually do when faced with a minor inconvenience: I decided to build my own solution.

Why I Built It

As a developer, I value transparency and control over my data. When dealing with something as significant as a mortgage, I want to see exactly how much of my monthly payment goes to interest versus the principal sum. Existing calculators often obscure the full amortization schedule or make it difficult to visualize the shift in the interest-to-principal ratio over time.

I set out to create a fast, lightweight tool that would provide an instant, detailed breakdown of the numbers right in the browser. No servers to ping, no waiting for a page to reload—just instant feedback as you adjust the loan amount, interest rate, or tenure.

The Tech Stack

To keep the application responsive and straightforward, I opted for a purely client-side architecture. Here is what I used:

Frontend Core: HTML5, CSS3, and Vanilla JavaScript. For a single-purpose mathematical utility, bypassing a heavy framework like React or Angular allowed me to keep the bundle size incredibly small and the initial load time nearly instantaneous.
Data Visualization: Chart.js. Visualizing the data is critical for a loan calculator. Chart.js provided an elegant way to render interactive pie charts for the total cost breakdown and bar graphs for the yearly amortization trends.
Hosting: Deployed as a static website, ensuring it is always available and lightning-fast.

Technical Challenges

At first glance, calculating an Equated Monthly Installment (EMI) seems like a simple task. The core formula is well-known: E = P * r * (1 + r)^n / ((1 + r)^n - 1).

However, the complexity arises when you move past the single monthly payment and generate the full amortization schedule. For a typical 30-year loan, that involves 360 months of sequential calculations.

The Floating-Point Precision Trap: As many developers know, JavaScript's handling of floating-point arithmetic can introduce subtle rounding errors. When you are calculating interest, subtracting it from a payment, applying the remainder to a principal, and repeating this 360 times, those tiny errors compound. I had to implement careful rounding logic at each step of the loop to ensure the final balance resolved cleanly to zero, mirroring a bank's strict ledger rules.
Dynamic UI Performance: I wanted the charts and tables to update in real-time as the user adjusted the sliders or input fields. Re-rendering a table with hundreds of rows and updating a canvas-based chart dynamically required optimizing DOM updates to prevent the interface from feeling sluggish during rapid input changes.
Handling Edge Cases: Financial tools need to be robust. What happens if a user inputs a 0% interest rate? (The standard formula divides by zero). What about massive loan amounts or unusually short tenures? Building in safeguards to handle these inputs gracefully without throwing NaN errors or freezing the browser was a key part of the development process.

Lessons Learned

Building this calculator was a great exercise in translating strict mathematical rules into a fluid user interface. It reinforced the importance of writing robust unit tests for edge cases, especially when dealing with financial logic where precision is non-negotiable.

More importantly, it reminded me of the satisfaction that comes from building a utility to solve a personal, real-world problem. Sometimes, a complex backend architecture is unnecessary. Client-side computation is powerful, secure (since no personal financial data leaves the user's device), and provides an exceptional user experience.

If you are currently evaluating real estate options, planning your financial future, or just want to play around with the math to see how reducing balance loans function, you can try out the application here: Home Loan EMI Calculator.

Conclusion

Working on focused, standalone projects is an excellent way to keep your programming fundamentals sharp. What began as a weekend project to understand my own financial options has evolved into a clean, accessible web application that anyone can use.

Have you ever built a tool just to solve a personal math or finance problem? I would love to hear how you handle precision and state management in your own utility apps!

Keeping it Simple: Building a Frictionless Markdown to HTML Converter

Getinfo Toyou — Mon, 27 Apr 2026 14:31:26 +0000

We've all been there. You write a brilliant piece of documentation, a technical blog post, or a comprehensive README in Markdown. It looks great in your local environment. But then you need to drop that content into an older CMS, an email client, or a platform that strictly requires HTML. Suddenly, your clean text becomes a puzzle of broken formatting, missing headings, and weird spacing. You just need the HTML, but getting it cleanly feels like a chore.

Why I built it

I found myself in this loop too often. I was constantly switching between bloated editors that took too long to load, and questionable online converters that either required creating an account, bombarded me with intrusive pop-ups, or worse, injected strange, proprietary inline styles into my output.

I didn't want a full-fledged writing suite. I just wanted a clean, straightforward way to turn my Markdown into pristine, AI-optimized HTML without any extra friction. I wanted a tool that respected my time and my workflow. That's exactly why I built Aimarkdownpro. The guiding principle was pure simplicity. The workflow had to be obvious: paste your Markdown on one side, instantly get your HTML on the other, and get right back to the work that actually matters.

Technical Challenges

It's a common trap in development: building a simple tool is often harder than building a complex one. Every feature you decide to omit requires a conscious decision and restraint. The primary challenge wasn't necessarily parsing the Markdown itself—the ecosystem has fantastic, well-tested libraries for that.

The real technical hurdle was ensuring the output HTML was exceptionally clean. I wanted the generated markup to be semantic and easily digestible not just by browsers, but by AI agents and scrapers as well. This meant writing logic to strip away any unnecessary nesting, ensuring tags were used correctly and consistently.

Another significant challenge was performance. When you build a utility designed to save people time, any perceivable lag defeats the purpose. I spent a good amount of time optimizing the live preview so that the HTML updates instantly as you type, without causing layout thrashing or draining the user's battery.

Tech Stack

To align with the philosophy of simplicity, I kept the architecture incredibly lean. I chose to avoid heavy frontend frameworks that would add unnecessary overhead. The app runs primarily on vanilla JavaScript, which allows the application to load almost instantaneously. For parsing, I evaluated several libraries but settled on one that offered the best balance of speed and spec compliance.

I also implemented a custom sanitization step to ensure the resulting HTML is safe and free from cross-site scripting (XSS) vulnerabilities, which is a crucial consideration even for a simple client-side tool. The interface is styled with plain, modern CSS to keep the bundle size tiny and the rendering fast. There's no complex build step, no state management libraries to untangle—just the browser executing clean code.

Lessons Learned

Building this project was a great reminder that solving your own small, specific problems is often the best path to creating something genuinely useful for the wider community. By maintaining a laser focus on the core use case—Markdown in, clean HTML out—I successfully avoided the temptation of feature creep.

I also learned that developers, technical writers, and content creators deeply appreciate tools that have a singular focus. We all have enough complex software in our lives; sometimes, a utility that does exactly one thing well and then gracefully gets out of the way is exactly what you need.

Conclusion

If you are tired of wrestling with overcomplicated formatting suites or dealing with messy output from subpar converters, I'd love for you to give this a try. It is entirely free to use and designed specifically to remove friction from your writing process.

You can check out the clean workspace and test your own Markdown at https://aimarkdownpro.getinfotoyou.com. I'm always looking to refine the experience, so if you have any feedback or ideas on how to make it even more straightforward, please share them. Keep your markup clean and your workflow simple!

Escaping Tutorial Hell: Building an Interactive Code Execution Environment

Getinfo Toyou — Fri, 24 Apr 2026 14:31:55 +0000

We've all been there. You just finished a comprehensive, four-hour video course on modern web development. You understand the concepts, you nodded along with the instructor, and you feel ready to build. Then, you open your code editor, stare at the blinking cursor, and realize you have absolutely no idea how to start.

This is "tutorial hell"—the frustrating cycle of passively consuming educational content without ever building the muscle memory required to actually write code. When I started my own development journey, I spent way too much time in this loop. Watching someone else solve a problem is entirely different from debugging your own typos and logic errors.

Why I Built It

I wanted a solution that bridged the gap between passive reading and independent building. I realized that the most effective way to learn programming is through immediate, interactive feedback. You need to write a small piece of code, run it, see it fail, fix it, and watch it pass.

That's why I built Javascript—an interactive web platform designed specifically to guide beginners and aspiring developers through hands-on programming lessons. The goal wasn't just to provide more reading material, but to create a sandbox where you can practice coding step-by-step, right in your browser.

The Tech Stack

Building an interactive learning environment requires a solid, responsive stack. For this project, I chose:

Frontend: React.js to handle the complex state of the code editor and lesson progression.
Code Editor: Monaco Editor (the engine behind VS Code) to provide syntax highlighting, auto-completion, and a familiar feel.
Backend: Node.js and Express to manage user progress, handle API requests, and coordinate code execution.
Infrastructure: Docker containers for securely running untrusted user code in isolated environments.

Technical Challenges

The hardest part of building an interactive coding platform is, without a doubt, safely executing code submitted by users. You cannot simply run arbitrary JavaScript on your main server using eval() unless you want to invite disaster.

My initial challenge was figuring out how to sandbox the execution. I experimented with Web Workers to run the code entirely on the client side. While this is fast and reduces server load, it makes it difficult to reliably run backend-focused challenges or prevent clever users from bypassing the test cases.

Eventually, I settled on a hybrid approach. Simple logic exercises run in the browser using isolated Web Workers, providing instant feedback. More complex scenarios involving file systems or network requests are sent to the backend, where they are executed inside ephemeral Docker containers. Managing the lifecycle of these containers—starting them quickly, enforcing strict memory limits, and tearing them down before they consume too many resources—was a significant architectural hurdle.

Another major challenge was state management. A user might start a lesson, modify the code, navigate away to read a hint, and then come back. Ensuring their unsubmitted code was preserved without aggressively hammering the database required careful implementation of local storage caching synchronized with background database updates.

Lessons Learned

Feedback loops must be tight: If a user has to wait more than a second to see the result of their code, their focus breaks. Optimizing the execution pipeline became a top priority over adding new features.
Edge cases in user code are endless: Beginners will write infinite loops, allocate massive arrays, and find syntax errors I didn't even know were possible. Building robust error handling that translates cryptic engine errors into human-readable advice was crucial for the platform's value.
Sandboxing is an ongoing battle: Security in an application designed to execute user code is never "finished." It requires constant monitoring and updating.

Conclusion

Building this platform taught me as much about system architecture as it did about product design. The transition from a passive observer to an active creator is a critical step for any aspiring developer, and I hope this tool makes that transition a little smoother.

If you are tired of just watching tutorials and want to start actually writing code, I'd love for you to try out the interactive lessons at Javascript. The platform is designed to help you build real-world skills step-by-step. Let me know what you think of the learning experience!

Stop Uploading Your Images to Random Servers Just to Resize Them

Getinfo Toyou — Wed, 22 Apr 2026 14:31:38 +0000

We've all been there. You have a massive 5MB image from your phone, and you just need it to be a 200KB JPEG for your blog or website. You search for "image resizer", click the first result, and wait while your photo uploads to who-knows-where, gets processed on a slow server, and then downloads back to your machine. It works, but it's slow, and honestly, a bit of a privacy nightmare. I got tired of this workflow, so I built a tool that handles it all right in the browser.

Why I built it

The core problem with most free image compression tools is the server round-trip. When you're formatting images for a website, you want it done instantly. Waiting for uploads, especially on a slow connection, breaks your flow. Plus, what if you're working with sensitive client images? Uploading them to a random free utility site isn't exactly best practice.

I realized that with modern web APIs, we shouldn't need a backend server just to scale an image or change its format. I wanted a solution that was fast, private by default, and entirely client-side. That's why I created Imageslim.

Technical Challenges

Building a purely client-side image processor sounds simple until you get into the weeds of browser memory limits and format support.

One of the biggest hurdles was handling HEIC files. iOS defaults to HEIC, but web browsers natively struggle to display or process them. Finding a way to decode HEIC efficiently in the browser without completely locking up the main thread was tricky. I had to leverage WebAssembly (Wasm) to handle the heavy lifting of format conversion locally, translating HEIC into a format the canvas could manipulate.

Another challenge was managing the actual resizing process while maintaining quality. The standard <canvas> element provides a quick way to scale images, but the default interpolation algorithms in some browsers can sometimes leave artifacts if you are scaling down significantly. Balancing speed with output quality required tweaking compression parameters and understanding how different browsers handle canvas image data extraction.

Tech Stack

I wanted to keep the application lightweight and responsive, avoiding heavy frameworks where they weren't necessary.

Frontend: HTML, CSS, and Vanilla JavaScript to keep the bundle size small and the execution fast.
Processing: HTML5 Canvas API for the core resizing and compression logic. WebAssembly for decoding complex file types.
Infrastructure: Static hosting. Since there is zero backend processing, the site is just a set of static files delivered quickly via CDN.

Lessons Learned

The most significant takeaway from building Imageslim is realizing how capable the modern browser has become. We often default to spinning up an API or a serverless function for tasks that can be handled perfectly well right on the user's device. Pushing this workload to the client not only saves on server costs but significantly improves the user experience by reducing network latency to zero.

Working with WebAssembly also opened my eyes to its practical applications. It's a reliable way to bring complex computational tasks to the frontend, bridging the gap between traditional desktop software capabilities and web applications.

Conclusion

If you regularly need to shrink photos for web development, blogging, or content creation, and you're tired of waiting for progress bars on server-side tools, give this approach a try. Everything happens locally on your machine, making it a secure and fast solution for formatting photos.

You can test out the live project here: https://imageslim.getinfotoyou.com

I'd love to hear your thoughts or if you've run into similar challenges building client-side web tools. Let me know in the comments!

Building Sharp QR: Tackling Android Camera APIs and Real-Time Barcode Scanning

Getinfo Toyou — Mon, 20 Apr 2026 14:33:39 +0000

If you search the Google Play Store for a QR code scanner, you will immediately be hit with an endless wall of results. It is one of the most saturated categories on the platform. So, why would any developer willingly choose to build another one?

The answer is simple: developer frustration.

Every time I needed to quickly scan a menu, a WiFi credential, or a conference badge, I found myself downloading an app that was either bloated with full-screen ads, requested intrusive permissions like contact access, or simply struggled to focus on a code in low light. I wanted a clean, privacy-respecting utility that did exactly two things well: scan codes with high precision and generate them on the fly.

That frustration led to the creation of Sharp QR. Here is a look under the hood at how I built it, the tech stack I chose, and the hurdles of working with Android's camera hardware.

The Tech Stack

For this project, I wanted to use a modern, robust Android stack. I chose:

Kotlin: The undisputed standard for modern Android development.
Jetpack Compose: For building a reactive, declarative user interface.
CameraX: To handle the notoriously difficult Android camera hardware APIs.
Google ML Kit (Barcode Scanning API): For on-device, machine learning-powered barcode detection.
Room & Coroutines: For handling the local database to save scan history.

The Technical Challenges

Building a camera app is rarely straightforward. Even with modern libraries, dealing with hardware sensors across thousands of different Android device models introduces edge cases.

1. Taming the Camera Lifecycle with Compose
One of the first challenges was integrating CameraX with Jetpack Compose. CameraX is inherently lifecycle-aware, but bridging that imperative API with Compose's declarative state management required some boilerplate. I had to ensure the PreviewView properly bound and unbound to the Android lifecycle owner, handling backgrounding, screen rotations, and permission grants without crashing or freezing the camera preview.

2. High-Speed Frame Processing
The core feature of Sharp QR is speed. I wanted the app to recognize a QR code the millisecond it entered the frame. To do this, I fed the CameraX image stream directly into Google's ML Kit.

The technical hurdle here was backpressure. The camera hardware generates frames much faster than the ML Kit analyzer can process them. If you queue every frame, the app will quickly run out of memory or experience severe lag. The solution was implementing ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST. This ensures that if the analyzer is busy, older frames are dropped, and it only processes the most recent image. This resulted in a snappy, responsive scanning experience without battery drain.

3. Generating Crisp Codes
Beyond scanning, Sharp QR allows users to generate custom codes for URLs, text, and contact info. Generating the QR matrix requires encoding the data and mapping it to a Bitmap. The challenge was ensuring these generated bitmaps were rendered sharply on high-density displays (xxhdpi/xxxhdpi) without artifacting, especially when users try to export or share them. I utilized a customized encoding algorithm to output clean, perfectly contrasted PNGs.

Lessons Learned

Building Sharp QR taught me a lot about the current state of Android development.

First, ML Kit is a massive improvement over older image processing libraries. The machine learning models are incredibly resilient to poor lighting, skewed angles, and partially damaged codes.

Second, while CameraX abstracts away the nightmare of the older camera2 API, testing on physical devices is still mandatory. Emulators simply cannot replicate autofocus quirks or hardware-level frame rate drops.

Conclusion

What started as a weekend project to solve a personal annoyance turned into a deeply educational dive into modern Android hardware APIs. I built Sharp QR to be the exact tool I wanted on my own phone—fast, precise, and completely focused on the user's task.

If you are an Android user, a marketer dealing with campaign codes, or just someone who appreciates a straightforward utility without the fluff, I would love for you to try it out. You can grab Sharp QR on Google Play: https://play.google.com/store/apps/details?id=com.getinfotoyou.sharpqr

Let me know how quickly it scans for you, and feel free to ask any questions about the CameraX implementation in the comments!

The Architecture of Simplicity: Building Echo Runner for Android

Getinfo Toyou — Sat, 18 Apr 2026 07:52:34 +0000

Mobile gaming has gotten incredibly complicated. When I set out to build Echo Runner, my primary goal as a solo developer was to strip away the noise. I wanted an endless runner for Android that you could open and immediately understand—run, dodge, survive. No forced five-minute tutorials, no confusing meta-game mechanics, and no cluttered interfaces. Just pure, fast-paced arcade action.

Why I Built It

As I build out my portfolio at getinfotoyou.com, I spend a lot of time analyzing what makes an application sticky. The answer almost always points back to ease of use. I built Echo Runner because I missed the days when mobile games were straightforward and respectful of the player's time.

The core loop is intentionally simple: collect power-ups, avoid obstacles, and chase the leaderboard. Designing for simplicity meant every mechanic had to justify its existence. If a feature didn't make the running experience more engaging or intuitive, it was cut entirely from the design document.

The Tech Stack

To bring this project to life, I chose the Godot Engine, writing the core logic in C#. Godot's node-based architecture is highly intuitive and allowed me to prototype the core movement physics within a single weekend.

For the Android deployment, Godot's export pipeline is streamlined and reliable. I also utilized a custom, lightweight shader system for the dynamic level environments. This kept the visual style clean and readable, ensuring the screen never felt too busy, while also keeping the frame rate high on older hardware.

Technical Challenges

The biggest hurdle in creating a "simple" endless runner is that the underlying systems are quite complex. The illusion of an endless, smooth world requires continuous procedural generation and strict memory management.

Object Pooling to Prevent Stutters
In early builds, instantiating and destroying obstacle nodes on the fly caused noticeable micro-stutters due to garbage collection. In a fast-paced game, a dropped frame usually means an unfair game over. To fix this, I implemented an object pool pattern. Obstacles and power-ups are pre-loaded into memory at startup. As the player moves forward, these objects are simply activated, deactivated, and repositioned, completely removing instantiation overhead.

Seamless Procedural Generation
The level generation logic had to provide variety while maintaining an accessible difficulty curve. I built a chunk-based loading system where predefined level segments are stitched together dynamically using a weighted randomization algorithm. This ensures the player never encounters an impossible sequence of obstacles, preserving that crucial ease of use and fairness.

Input Latency
Ease of use dies immediately if the controls feel sluggish. I spent weeks refining the input handling so that dodges and jumps register exactly when the player expects them to. By polling touch input at the very start of the engine's physics process step, the game feels highly responsive.

Lessons Learned

The most valuable lesson from this project was that minimal design leaves absolutely nowhere to hide. When your game only has a few core mechanics, they have to feel perfect.

I also learned the importance of indirect feedback. Because the user interface is so minimal, the game relies heavily on subtle particle effects, slight camera movements, and crisp audio cues to communicate success or failure to the player. Balancing these elements so they feel impactful without becoming overwhelming took extensive iteration.

Try It Out

If you are an Android user looking for a straightforward, free-to-play casual game to kill a few minutes on your commute, I would love for you to give it a try.

You can grab it directly from the Google Play Store: Echo Runner Game
Or check out the landing page on my portfolio: echorunner.getinfotoyou.com

Conclusion

Building something simple is often the hardest challenge for a developer. Echo Runner was an exercise in restraint just as much as it was in software engineering. I am currently working on adding a few more obstacle variations while strictly adhering to the "easy to learn, hard to master" philosophy. Let me know what you think if you decide to take it for a spin!

Building a Better Mobile Markdown Experience: The Story Behind AIMarkdownPro

Getinfo Toyou — Fri, 17 Apr 2026 12:55:49 +0000

As developers, we live and breathe Markdown. From documenting our code in README files to drafting technical blog posts, it is the universal language of our trade. But while our desktop environments are perfectly tuned for writing Markdown—complete with live previews, linting, and macros—the experience on mobile devices has often felt like an afterthought.

I found myself frequently wanting to jot down technical ideas, draft API documentation, or start a blog post while commuting or away from my desk. The existing Android apps I tried either lacked robust syntax highlighting, had clunky preview mechanisms, or completely ignored the growing utility of AI for helping structure thoughts and refine text. I didn't just want a note-taking app; I wanted a capable development tool in my pocket. That frustration is exactly why I built AIMarkdownPro Editor.

The Vision

The goal was straightforward: create an Android Markdown editor that feels as powerful as a desktop IDE. It needed a smooth live preview, proper syntax highlighting for code blocks, and AI assistance integrated directly into the writing flow to help overcome writer's block or rephrase awkward sentences.

The Tech Stack

To build a responsive and modern Android app, I went with a fully native approach:

Language: Kotlin, leveraging coroutines for asynchronous operations.
UI Framework: Jetpack Compose. Building the complex, dynamic layouts required for a split-screen editor and preview felt much more intuitive with Compose compared to XML layouts.
Local Storage: Room database to ensure all documents are saved securely and instantly on the device.
Networking: Retrofit for communicating with the AI backend services.
Markdown Rendering: I utilized the Markwon library. This was a critical choice; rendering Markdown natively to Android TextViews rather than relying on a heavy WebView keeps the app fast and battery-efficient.

Technical Challenges

Building a text editor is notoriously difficult, and doing it on mobile brings unique constraints.

1. Syntax Highlighting in Real-Time
Implementing syntax highlighting as the user types, without dropping frames or causing input lag, was a significant hurdle. Processing regular expressions over large text blocks on the main thread is a recipe for ANRs (Application Not Responding). I had to heavily optimize the parsing logic, using debouncing techniques and offloading the heavy lifting to background threads before applying styling spans to the text.

2. Integrating AI Seamlessly
I wanted the AI to feel like a pair-writer. This meant the AI's suggestions needed to flow naturally into the document. Handling the streaming responses from the AI API and updating the editor's text buffer dynamically, while maintaining the correct cursor position and not interfering with the user if they continued typing, required careful state management.

3. The Split-Screen Experience
Providing a live preview that updates instantly alongside the editor is tough on smaller screens. Designing a UI that handles software keyboard pop-ups, screen rotations, and foldable devices without breaking the layout or obscuring the text was an iterative process of testing and refinement using Compose's flexible layout modifiers.

Lessons Learned

Through building AIMarkdownPro, I gained a profound respect for the complexity of text rendering and input management on Android. Handling different software keyboards, autocorrect behaviors, and text selection spans is a deep rabbit hole.

I also learned that AI features are only useful if they are fast. If a user has to wait more than a few seconds for a phrasing suggestion, the context is lost, and they will likely just write it themselves. Optimizing the backend prompts and prioritizing low-latency network calls became just as important as the UI itself.

Try It Out

AIMarkdownPro Editor was built to scratch my own itch, and it has successfully become my daily driver for drafting technical content on the go. If you are a developer, technical writer, or blogger looking for a more capable mobile writing environment, I'd love for you to check it out.

You can download it from Google Play or learn more at aimarkdownpro.getinfotoyou.com.

Let me know how it fits into your workflow!

How I Built a Batch Image Compressor for Android That Handles 500 Photos at Once

Getinfo Toyou — Wed, 15 Apr 2026 14:38:32 +0000

The Problem That Started It All

A photographer friend of mine had a familiar complaint: she'd shoot 400+ RAW-converted JPEGs at an event, and getting them web-ready meant either a slow desktop workflow or uploading massive files directly to her clients. She was constantly tethered to her laptop for a task that felt like it should be solvable on her phone.

That conversation is what pushed me to build ImageSlim Pro — a professional-grade image compression and batch processing tool for Android.

The Use Case That Shaped Everything

Imagine you're a real estate photographer. You shoot 300 photos of a property, transfer them to your Android device, and need to deliver a web-optimized folder to the agent before you leave the driveway. You don't want generic auto-compression. You need to hit a specific file size range, maintain consistent quality across the batch, and output to a particular format — maybe WebP for a modern site, or JPEG at a defined quality level for an older CMS.

This scenario drove every design decision. It's not about compressing one photo. It's about compressing all of them, with precision, in under a minute.

The Tech Stack

Language: Kotlin
Image processing: Android's native BitmapFactory and Bitmap.compress(), supplemented with custom quality-stepping logic
Format conversion: Handled via encoder selection at the compression stage (JPEG, PNG, WebP lossy/lossless)
UI: Jetpack Compose for a clean, responsive interface
File handling: Scoped storage with SAF (Storage Access Framework) to support modern Android versions
Threading: Kotlin Coroutines with a custom dispatcher pool for parallel batch processing

The Hard Parts

1. Predictable Output File Sizes

This sounds simple until you try it. JPEG quality settings are not linear. Quality 80 might give you a 200KB file on one image and a 900KB file on another, depending on the photo's complexity. I ended up implementing a binary search loop — compress at a target quality, check output size, adjust, repeat — to land within a user-defined file size target. It adds a small processing overhead but gives users the predictability they actually need.

2. Batch Processing Without Killing the UI

Processing 500 images sequentially on the main thread is an obvious disaster. But naively spinning up 500 coroutines in parallel would also hammer memory and cause OOM crashes on mid-range devices. The solution was a bounded coroutine pool — a Semaphore-limited dispatcher that processes N images concurrently (tuned based on available heap) while keeping the UI responsive and showing real-time progress.

3. Scoped Storage on Android 10+

Scoped storage broke a lot of older file-handling patterns. Working with SAF (Storage Access Framework) is more verbose and less intuitive than classic File APIs, but it's necessary for proper permission handling on modern Android. I spent more time on this than I'd like to admit. The key takeaway: persist your URI permissions explicitly with takePersistableUriPermission() or you'll lose access after a reboot.

4. WebP Compatibility

WebP support on Android is fragmented. Lossy WebP is available from API 17+, but lossless and transparency support requires API 18+. I added runtime version checks and gracefully fall back or inform users when a format option isn't supported on their device.

Lessons Learned

Target a specific workflow, not a general one. The clearest feedback I got from beta testers was about concrete scenarios — real estate photographers, e-commerce sellers prepping product photos, bloggers batching header images. Building around those use cases made the feature set coherent instead of sprawling.

File size targeting is a killer feature that most tools ignore. Users don't think in "quality percentage" — they think in "I need all images under 500KB." Bridging that gap was worth the engineering effort.

Coroutine-based parallelism is excellent for media work — but set your bounds carefully. Unbounded parallelism on image data will eat your memory budget fast.

Try It Yourself

If you work with images on Android regularly, give ImageSlim Pro on Google Play a shot. There's also more info at imageslim.getinfotoyou.com.

Happy to answer questions about any of the implementation details in the comments — especially around the batch processing architecture or scoped storage pain points, since those tripped me up the most.

Building an Offline Image Compressor for Android: Solving the Slow Wi-Fi Problem

Getinfo Toyou — Mon, 13 Apr 2026 14:31:20 +0000

Have you ever been traveling, taking hundreds of photos, only to realize your phone's storage is almost full? Or maybe you're a developer or blogger trying to upload high-resolution images from a spotty hotel Wi-Fi connection? Relying on cloud storage or online compression tools isn't always practical when you're off the grid or dealing with limited bandwidth.

That specific scenario—needing to shrink images fast without relying on the internet—led me to build ImageSlim Free, an Android app designed to compress and resize photos directly on your device.

The Problem

Modern smartphones take high-quality photos, but those large sensors produce hefty file sizes. A single photo can easily be 5-10MB. If you need to share these images on a platform with strict file size limits, or if you're just trying to reclaim some local storage, you need a way to compress them.

While there are plenty of web-based tools, they require uploading your private photos to a server. This is slow, consumes mobile data, and raises privacy concerns. I wanted a fast, private, and completely offline solution.

The Tech Stack

To keep the app lightweight and performant, I stuck to the native Android ecosystem:

Language: Kotlin
UI: XML/View system
Image Processing: Native Android Bitmap APIs and BitmapFactory, supplemented by Kotlin Coroutines for asynchronous, non-blocking processing.
Storage: MediaStore APIs to securely read from and write to the user's gallery.

Technical Challenges

Building an image compressor sounds simple until you actually try to load multiple 10MB images into memory on a mobile device.

1. OutOfMemoryError (OOM)
This is a classic Android developer hurdle. Loading a full-resolution bitmap into memory can easily consume a large amount of RAM. If a user selects a batch of photos to compress, trying to hold them all in memory will crash the app instantly.

The Fix: Instead of loading the entire image at once, I utilized BitmapFactory.Options with inJustDecodeBounds = true to read the image dimensions first. Then, I calculated an appropriate inSampleSize to load a scaled-down version into memory before applying the final compression using Bitmap.compress().

2. Scoped Storage complexities
Managing file permissions has become much stricter in recent Android versions. Ensuring the app could efficiently read original photos and save the compressed versions back to the Pictures directory without constantly prompting the user required careful handling of the MediaStore API.

3. Balancing Quality and Size
Finding the sweet spot between file size reduction and acceptable visual quality took a lot of testing. ImageSlim Free allows users to reduce image file size by up to 90%. Implementing the logic to dynamically adjust the JPEG/WEBP quality parameters while resizing the dimensions was key to achieving this without noticeable artifacting.

Lessons Learned

Building ImageSlim Free reinforced the importance of memory profiling. Tools like the Android Studio Memory Profiler were invaluable in tracking down memory spikes and optimizing the image processing pipeline. I also learned that edge cases in Android's MediaStore are plentiful—different device manufacturers implement the gallery slightly differently, requiring robust error handling.

If you ever find yourself needing to shrink photos for a blog post, an email, or just to save space on your phone while traveling, it might be exactly what you need. It works completely offline.

You can try ImageSlim Free on Google Play or learn more at imageslim.getinfotoyou.com. Let me know what you think or if you have any questions about handling Bitmaps in Android!

Stop Losing Your Prompts: Why I Built a Local Vault for AI Interactions

Getinfo Toyou — Fri, 10 Apr 2026 03:44:54 +0000

As developers, we are increasingly integrating AI into our daily workflows. Whether it's drafting boilerplate code, generating complex regex patterns, or debugging obscure error messages, tools like ChatGPT, Claude, and Gemini have become indispensable to our productivity. But there is a recurring friction point I noticed in my own routine: the really good prompts always seem to get lost. You might spend ten minutes refining the perfect prompt to generate a specific API structure, use it once, and then watch it disappear into the endless, unsearchable scroll of your chat history. I needed a better solution for my own sanity, so I built AI Prompt Vault.

The Problem with Chat Histories

Chat interfaces are designed for linear conversations, not long-term knowledge management. When you want to reuse a prompt that worked exceptionally well last week, your options are usually poor. You either have to scroll endlessly through dozens of disjointed conversations, try to search for keywords hoping you remember the exact phrasing, or maintain a messy, disorganized text file on your desktop. None of these solutions scale as your reliance on AI grows. I realized I was spending almost as much time looking for old prompts as I was writing new ones, which completely defeated the purpose of using AI for efficiency.

The Solution: AI Prompt Vault

I decided to build a dedicated tool to manage this highly specific type of data. AI Prompt Vault is an Android app designed to serve as a personal repository for your AI interactions. The core idea is simple but focused: save your prompts, organize them by category or project, search through them instantly, and copy them to your clipboard with a single tap.

Why an Android App?

While a web app or a browser extension might seem like the obvious choice for a desktop-heavy workflow, I often find myself thinking about architectural problems or drafting ideas on my phone while away from my desk. Having a mobile-first vault means I can capture prompt ideas whenever inspiration strikes. It also serves as a fantastic reference tool when discussing AI workflows with colleagues away from a computer.

The Tech Stack

For this project, I opted for a modern, robust Android development stack:

Kotlin: The language of choice for its conciseness, null safety, and excellent standard library.
Jetpack Compose: I used Compose for building the UI. The declarative approach made iterating on the list views, search interfaces, and categorization screens much faster and more intuitive than dealing with traditional XML layouts.
Room Database: For local, offline-first storage. Prompts don't necessarily need to live in the cloud, and having instantaneous local search without network latency is a huge usability win.
Coroutines & Flow: Essential for handling asynchronous database operations and ensuring reactive, jank-free UI updates as the user searches or filters their library.

Technical Challenges

One of the main challenges was designing an intuitive and scalable categorization system. A flat list of prompts becomes unmanageable quickly once you pass the 50-item mark. I implemented a flexible tagging and folder system. This required some careful database schema design within Room to ensure many-to-many relationships (prompts to multiple tags) could be queried efficiently without slowing down the main UI thread during live searches.

Another interesting hurdle was handling the "copy to clipboard" functionality gracefully across the fragmented Android ecosystem. Android's clipboard manager can sometimes behave differently depending on the OEM skin (Samsung, Pixel, Xiaomi, etc.). Ensuring a consistent visual feedback mechanism—like a perfectly timed Snackbar—immediately after copying was crucial for user confidence, so they know the action succeeded without needing to double-check.

Lessons Learned

Building AI Prompt Vault reinforced the classic developer adage: scratching your own itch is often the best way to find a meaningful project. By solving a problem I faced daily, I was able to design the user experience exactly how a power user would need it.

I also learned that simplicity is often the most valuable feature. It is incredibly tempting to add complex integrations with every AI API available, but the core value of this app is simply having a reliable, fast place to store and retrieve text. Keeping the scope focused allowed me to polish the core experience—speed and organization—rather than delivering a bloated, buggy application.

Conclusion

If you find yourself repeatedly typing out the same context for your AI assistants, or constantly losing your most effective prompts in the chat abyss, you might find this tool genuinely useful for your workflow. You can check out AI Prompt Vault on Google Play. It is a straightforward, no-nonsense way to keep your AI workflows organized and efficient. I'd love to hear how other developers are managing their prompt libraries—let me know in the comments!