DEV Community: Getinfo Toyou

Building EasierRenter: Replacing Landlord Spreadsheets with a Focused Android App

Getinfo Toyou — Fri, 29 May 2026 14:30:57 +0000

If you've ever talked to a solo landlord or an independent property manager, you quickly realize they all share a common enemy: the spreadsheet. It starts simple enough—a few columns for rent due dates, tenant names, and contact info. But as a portfolio grows, that simple spreadsheet becomes a brittle, confusing mess of color-coded cells, broken formulas, and overlapping lease dates.

I wanted to tackle this specific problem. Managing rental units shouldn't require an accounting degree or a complex desktop suite. That is why I built EasierRenter, an Android app designed to simplify property management, track leases, and handle rent payments from a single, portable dashboard. Here is a look under the hood at why I built it, the stack I chose, and the technical challenges I ran into along the way.

The Problem It Solves

Before diving into the code, it helps to understand the user's underlying pain point. Landlords are constantly juggling moving targets: when does a specific lease end? When is rent due for unit B? Who is late this month, and by how much? Relying on memory or manual calendar entries almost always leads to missed income and frustrated tenants.

EasierRenter tackles this by automating the mental overhead. It provides automated rent reminders, tracks payment history chronologically, and generates financial reports. By focusing strictly on the core problem—tracking who owes what and when—the app keeps property managers organized without overwhelming them with unnecessary enterprise features.

The Tech Stack

To build this, I went with a modern, native Android development stack designed for maintainability and performance:

Language: Kotlin. It is concise, expressive, and provides excellent null safety, which is crucial when handling user-inputted financial data.
UI Framework: Jetpack Compose. Building the UI declaratively saved me countless hours, especially when creating the dynamic dashboard and generating custom reporting charts.
Architecture: MVVM (Model-View-ViewModel) paired with Clean Architecture principles to keep the business logic tightly separated from the UI layer.
Local Data: Room Database. Fast, offline-first capabilities are absolutely essential because users might be out inspecting properties or in basements with poor cell reception.
Asynchrony: Kotlin Coroutines and Flows. These were vital for passing real-time database updates up to the UI smoothly.
Background Tasks: WorkManager. Essential for handling the automated rent reminders reliably behind the scenes.

Technical Challenges

Building an app that handles relational data and scheduling comes with a specific set of hurdles.

1. Reliable Scheduling for Reminders
One of the core features is automated rent reminders. Relying on basic system alarms isn't sufficient on modern Android devices due to aggressive battery optimization (Doze mode). I had to implement WorkManager to ensure these scheduled tasks fired reliably without draining the user's battery. Handling timezones and daylight saving time shifts for lease start and end dates also required careful implementation of the java.time API to prevent off-by-one-day errors.

2. Complex State Management in Compose
A property manager's dashboard needs to aggregate data from multiple related database tables: Properties, Units, Tenants, Leases, and Payments. Flowing this data up into a single cohesive UI state in Jetpack Compose was tricky. I learned quickly that pushing too much transformation logic into the ViewModel made the app sluggish. I had to refine my repository layer to emit heavily optimized SQL queries via Room and Flows, ensuring the UI only recomposed when the underlying data actually changed.

3. Designing for Density
Fitting a comprehensive financial summary onto a mobile screen without it looking cluttered was a significant design challenge. I iterated on the UI multiple times, moving from dense, text-heavy lists to visual cards and simple progress bars that indicate payment collection status at a glance.

Lessons Learned

If there is one major takeaway from building EasierRenter, it is that offline-first architecture is hard but entirely worth the effort. Users expect an app to load instantly and save their inputs reliably, regardless of their network connection. Designing the SQLite database schema to handle complex relationships (a property has many units, a unit has a current lease and past leases, a lease has many payments) taught me a lot about optimizing queries and managing foreign key constraints on mobile.

I also learned that when building tools for business operations, reliability beats flashy animations every single time. Users do not care about a beautiful transition if the monthly financial report is calculated incorrectly.

Conclusion

Building EasierRenter has been a highly rewarding process. It took a stressful, scattered workflow and turned it into a focused, reliable mobile experience. If you are a developer looking to build utility apps, I highly recommend finding a manual, spreadsheet-heavy process and figuring out how to mobile-optimize it.

If you manage a few properties or just want to see how the app handles these complex data flows and UI challenges in practice, you can check it out on the Play Store.

You can download EasierRenter here: https://play.google.com/store/apps/details?id=com.getinfotoyou.easierrenter

I'd love to hear your thoughts on building offline-first apps or handling complex background scheduling in Android. Drop a comment below!

Handling Android Image Compression: From OutOfMemory Errors to a Streamlined Utility

Getinfo Toyou — Wed, 27 May 2026 14:30:37 +0000

Every developer or power user has faced the "file too large" wall. Whether you are trying to upload a high-resolution photo to a government portal, attach a batch of images to an email, or simply save some space on a phone that is nearing its storage limit, the struggle is real.

Modern smartphones take incredible photos, but those 12MB JPEGs are often overkill for a quick social media update or a documentation upload. I built ImageSlim Compress PhotoResize to bridge the gap between high-quality capture and practical file sizes.

The Hard Way vs. The Efficient Way

Before I built this tool, resizing an image on Android usually involved one of three frustrating paths:

The Desktop Round-Trip: Moving the photo to a PC via cloud storage or a cable, using a tool like Photoshop or GIMP to resize it, and then moving it back to the phone. It is precise, but it takes five minutes for a task that should take five seconds.
The Sketchy Web Converter: Using an ad-heavy website that asks you to upload your private photos to their server. You have no idea where those images go, and the mobile browser experience is often clunky.
The Heavyweight Editor: Opening a full-scale mobile photo editor. These apps are great for filters and retouching, but they are often bloated and require several taps just to find the "export resolution" setting.

I wanted a fourth option: a dedicated utility where you pick a photo, slide a quality bar, and get your result instantly. That is the philosophy behind ImageSlim.

The Technical Stack

I chose to build this as a native Android application using Kotlin. While cross-platform frameworks are popular, image manipulation requires direct access to system resources and memory management, which is often more predictable in a native environment.

UI Layer: Jetpack Compose. This allowed for a reactive UI that updates as compression tasks move through the queue.
Image Processing: I utilized the Android Bitmap API and ImageDecoder for modern devices.
Concurrency: Kotlin Coroutines were essential. Compressing multiple high-res images is a CPU-intensive task; doing it on the main thread would freeze the UI. Coroutines allow the app to process files in the background while keeping the interface responsive.

The Challenge of Memory Management

One of the biggest technical hurdles was avoiding OutOfMemoryError (OOM). If you try to load a 108-megapixel image into memory at full resolution, even a flagship phone might struggle.

To solve this, I implemented a two-step process. First, I read the image dimensions without loading the actual pixels (using inJustDecodeBounds). Then, I calculate a sample size to downsample the image during the initial load. This ensures the app only uses the memory it needs to perform the compression, making it stable even on older devices with limited RAM.

Another challenge was handling modern formats like HEIC and WebP. Converting these to standard JPEGs while preserving as much detail as possible required careful handling of the underlying bitstreams and color profiles.

Lessons Learned

Building a utility tool taught me that UX is just as important as the algorithm. Users don't care how efficient your bitstream processing is if they can't find the "Save" button. I spent a significant amount of time refining the batch processing workflow—allowing users to select fifty photos and shrink them all to a specific KB target in one go.

I also learned that transparency matters. People are protective of their photos. By keeping all processing local on the device and not requiring unnecessary permissions, I could provide a tool that is both helpful and respectful of privacy.

Conclusion

If you find yourself constantly fighting with file size limits or a "Storage Full" notification, you might find this useful. It is a simple tool designed to solve one problem effectively. You can check it out on the Google Play Store here: ImageSlim Compress PhotoResize.

Stop doing things the hard way and let your phone handle the heavy lifting.

Building an Offline QR Code Scanner for Android: The Hard Way vs. The Right Way

Getinfo Toyou — Mon, 25 May 2026 14:30:45 +0000

Why I Almost Gave Up Halfway Through

I've been building small utility apps for Android for a while now, and when I decided to build a QR code scanner, I thought it would be straightforward. It wasn't. But the struggle taught me more about mobile barcode processing than I expected — and the end result is Sharp QR, a reliable offline QR scanner and generator that actually works when you need it.

Let me walk you through what I learned, what I got wrong first, and why some of those wrong turns were actually instructive.

The Hard Way: Rolling Your Own Barcode Detection

My first instinct was to write a custom image processing pipeline. I wanted to understand the problem from the ground up. Here's what that looked like:

Manual camera frame capture using Camera2 API
Converting YUV buffers to grayscale bitmaps by hand
Applying threshold filters to improve contrast on faded codes
Writing finder pattern detection logic from scratch

The result? It kind of worked on high-contrast codes printed on white paper. Try it on a faded label on a cardboard box at a store, and it would just stare blankly back at you.

The performance was also rough. Processing frames on the main thread caused visible lag. Moving it to a background thread introduced synchronization bugs. I was spending weeks on infrastructure that had nothing to do with the user experience I actually wanted to deliver.

The Right Way: Standing on Solid Shoulders

I eventually stopped fighting the problem and reached for ML Kit's barcode scanning API. Combined with ZXing for QR code generation, this became the real foundation of Sharp QR.

Tech stack breakdown:

Language: Kotlin
Camera: CameraX (lifecycle-aware, much cleaner than Camera2 for this use case)
Scanning: ML Kit Barcode Scanning (on-device, works fully offline)
Generation: ZXing core library
UI: Material Design 3 components
Architecture: MVVM with ViewBinding

Switching to ML Kit didn't feel like giving up — it felt like making a smart engineering decision. The model runs entirely on-device. No network calls, no latency spikes, no privacy concerns about sending images to a server. That last point matters more than people realize when you're scanning things like Wi-Fi passwords or contact cards.

The Actual Technical Challenges

Even with the right libraries, there were real problems to solve:

1. Faded code recovery
ML Kit handles this better than my homebrew attempt, but I still had to tune the camera preview resolution and frame analysis rate. Too high a resolution and the analysis queue backs up. Too low and you miss detail on worn codes. CameraX's ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST was the key — it drops frames rather than queuing them.

2. Offline-first architecture
I wanted zero network dependency at runtime. ML Kit's bundled model option solved scanning. For QR generation (Wi-Fi credentials, vCards, URLs), everything is computed locally using ZXing's QRCodeWriter. The app literally works in airplane mode.

3. Format breadth
Users don't only scan QR codes. They scan Code 128 barcodes on grocery items, EAN-13 on retail products, Data Matrix codes on electronics. Supporting all of these without the UI becoming a format-picker maze required some UX thinking alongside the technical work.

Lessons Learned

Premature optimization of the wrong layer is a real trap. I spent days on image processing that a well-maintained library handled in hours of integration.
On-device ML is genuinely viable now. A few years ago, offline-capable ML on mobile felt like a tradeoff. Today, ML Kit's bundled models are fast and accurate enough that cloud processing feels unnecessary for this use case.
CameraX made lifecycle management actually manageable. If you're building anything camera-related on Android and you're still on Camera2 directly, reconsider.
Utility apps live or die on reliability. Users will forgive a plain UI. They won't forgive a scanner that fails on three codes in a row.

Try It

If you're on Android and want a no-fuss barcode tool that works without internet, give Sharp QR a try. It handles scanning and generation across all common formats, works offline, and doesn't ask for unnecessary permissions.

Building it was humbling in the right ways. The hard path clarified what the right path actually was — and the right path still had plenty of real engineering in it.

Happy to answer questions about any part of the stack in the comments.

Why I Built a Practical Photo Compressor for Android (And How I Did It)

Getinfo Toyou — Fri, 22 May 2026 14:40:04 +0000

As developers and heavy smartphone users, we often run into a common, frustrating issue: running out of storage space. With smartphone cameras constantly improving, photo file sizes have bloated to ridiculous proportions. Sometimes you just need to upload a quick picture for a web form, share it via email, or optimize assets for a quick project, and you hit a hard file size limit.

That's why I built ImageSlim Pro Photo Compressor. I wanted a reliable, straightforward tool that shrinks and resizes photos to save space without a noticeable drop in visual quality. And most importantly, I wanted to provide genuine value without nickel-and-diming users, which is why focusing on accessibility and offering a tool that actually helps you save space (and money on cloud storage upgrades) became my priority.

Why I Built It

The problem started when I realized I was paying monthly for extra cloud storage solely because my photo library was filled with massive 10MB to 15MB images. Many of these were just snapshots, receipts, or quick reference photos that didn’t need to be print-quality.

I looked around the Google Play Store for a solution. While there are many image resizers, many are riddled with intrusive ads, require expensive subscriptions, or just have poor user interfaces. As a solo developer at getinfotoyou.com, I saw an opportunity to build a clean, functional tool that solves this specific problem efficiently. ImageSlim Pro was born out of the necessity to manage local storage effectively and provide a high-value, cost-effective solution for smartphone users, social media managers, and fellow web developers who need optimized images on the go.

The Tech Stack

For an Android application that requires heavy image processing, performance and memory management are critical. I chose the following stack:

Language: Kotlin. It's concise, modern, and the standard for Android development, making asynchronous tasks much cleaner.
UI Framework: Android Views with Material Design components. While Jetpack Compose is gaining traction, I stuck with standard XML layouts for this iteration to ensure broad compatibility and fast initial rendering.
Image Processing Library: To handle the actual compression and resizing, I utilized a combination of Android's native BitmapFactory and highly optimized C++ libraries via JNI for the heavy lifting, ensuring the compression algorithms ran as quickly as possible without causing the main thread to stutter.
Concurrency: Kotlin Coroutines. Essential for moving the intensive image compression work off the main UI thread, keeping the app responsive.

Technical Challenges

Building an image compressor sounds straightforward until you have to deal with the Android memory model and varying device capabilities.

Out of Memory (OOM) Errors: Loading a 12-megapixel image directly into memory will crash most budget Android devices instantly. The biggest challenge was implementing efficient downsampling using inSampleSize before loading the full bitmap into memory, and then applying the more precise resizing and quality compression.
Preserving EXIF Data: Users want their photos compressed, but they usually don't want to lose the date, time, or location data attached to them. Reading, preserving, and rewriting EXIF metadata across different Android versions (especially with the introduction of Scoped Storage) required careful handling of ExifInterface and Uri permissions.
Balancing Quality vs. Size: Finding the sweet spot where file size is drastically reduced but the image still looks good to the human eye involved a lot of trial and error. I ended up implementing adjustable sliders so the user has the final say on the quality-to-size ratio.

Lessons Learned

The most valuable lesson I learned during this project was the importance of user experience in utility apps. People using a photo compressor are usually trying to accomplish a task quickly—like attaching an image to an email. Any friction in the app's flow is a reason for them to uninstall. Keeping the interface minimal, focusing on bulk processing capabilities, and providing immediate visual feedback on the storage saved were crucial steps in refining the app.

Also, dealing with Android's ever-changing file system permissions (like the transition to MediaStore and Scoped Storage) reinforced the need to constantly read the latest documentation and test on physical devices across various API levels.

Conclusion

Building ImageSlim Pro was a practical exercise in solving a personal pain point that turned out to be a widespread issue. By focusing on creating a genuinely useful, straightforward app, I was able to deliver something that saves users both storage space and money.

If you are a web developer who needs to quickly optimize assets from your phone, or just someone tired of the 'Storage Almost Full' warning, give it a try.

You can check it out here: ImageSlim Pro Photo Compressor

Let me know what you think, and if you have any feature requests, I'm always looking to improve it!

Building an Offline-First AI Prompt Manager: Tech Stack and Lessons Learned

Getinfo Toyou — Mon, 18 May 2026 14:34:35 +0000

It's estimated that regular users of large language models spend up to 30% of their interaction time simply recreating or tweaking prompts they've already used in the past. If you use AI frequently for coding, writing, or image generation, you likely know the feeling: you spend twenty minutes finding the exact phrasing that gets the response you need from Claude or Midjourney, only to lose it in a sea of chat history a few days later.

I found myself dealing with this constantly. My solution was a chaotic notes file filled with scattered instructions and parameters. It was disorganized, slow to navigate on mobile, and relied on an internet connection. I wanted a dedicated tool to store my prompts locally, find them instantly, and copy them without friction.

This led me to develop AI Prompt Vault -AI Helper Pro, an ad-free Android app designed to keep your most useful AI interactions structured and accessible entirely offline.

Why I Built It

I built this app to solve a personal workflow issue. General note-taking apps are versatile, but they lack the specific structure needed for prompt management. They don't have categorized tags for different AI models, quick copy buttons, or an interface built specifically for rapid retrieval.

Furthermore, I often work from coffee shops or on trains where the connection is spotty. I wanted a tool that respected my privacy, worked flawlessly without a network connection, and didn't interrupt the user experience with pop-up ads or subscription banners.

The Tech Stack

To ensure the application was fast and felt native to the device, I opted for a standard modern Android development stack:

Language: Kotlin
UI Framework: Jetpack Compose
Local Storage: Room Database (SQLite)
Architecture: MVVM (Model-View-ViewModel)

Technical Challenges

Creating a seemingly simple offline app brought its own set of technical hurdles, particularly when trying to match the performance expectations of modern mobile users.

1. Implementing Instant Offline Search
When managing hundreds of text-heavy prompts, standard SQL LIKE queries can become sluggish and resource-intensive. I needed the search functionality to feel instantaneous across titles, descriptions, and assigned categories as the user typed. To achieve this, I utilized Room's Full-Text Search (FTS4) capabilities. By creating a virtual table mapped to the core prompt data, the app can perform highly optimized text matching locally. This allows for complex searches without any noticeable lag or heavy battery drain.

2. Managing State in Jetpack Compose
Handling the UI state for a complex, filterable list requires careful architecture in Compose. Balancing active search queries, selected categories, and the list of prompts meant I had to optimize the ViewModel's state emission. Ensuring the UI only recomposed when necessary was crucial for maintaining smooth scrolling performance, especially on older devices.

3. Secure Local Backups
Because the app operates entirely offline without a backend server, I had to provide a reliable way for users to secure and migrate their data. Implementing a robust JSON export and import system using Android's Storage Access Framework (SAF) was surprisingly challenging. It required handling various edge cases across different device manufacturers' file pickers to ensure users could reliably backup and restore their prompt libraries.

Lessons Learned

The Value of Offline-First
In an ecosystem dominated by constant cloud-syncing, mandatory user accounts, and recurring subscriptions, I discovered there is still significant demand for utility software that operates independently. Users genuinely appreciate tools that load instantly, function on airplanes, and keep their personal data strictly on their device without sending telemetry back to a server.

Focusing on the Core Loop
The primary function of this app is simple: open, find the prompt, copy, and exit. I learned that adding extraneous features would only add friction to this loop. By keeping the design focused strictly on organization and retrieval, the app serves its specific purpose much better than a bloated alternative.

Conclusion

Developing AI Prompt Vault was a practical exercise in building a focused, privacy-respecting Android application. If you find yourself repeatedly typing similar instructions or losing your most effective prompts, having a dedicated local vault can save a considerable amount of time.

You can try the app here: AI Prompt Vault -AI Helper Pro.

If you have any thoughts on local data management in Android or prompt engineering workflows, I'd be interested to hear them in the comments.

Building a Batch Image Converter for Android: Overcoming Mobile Memory Limits

Getinfo Toyou — Fri, 15 May 2026 14:31:31 +0000

As developers, web designers, and digital creators, we frequently encounter the surprisingly tedious problem of image formatting. You might have a batch of heavy PNGs, but a client's website strict upload rules require WebPs under 500KB. Or maybe you just need to share a dozen high-res photos with your team without hitting email attachment limits. I found myself repeatedly looking for a fast, straightforward way to handle this directly on my phone, without needing to boot up a laptop or upload my private files to a random server. That friction is the exact problem I set out to solve.

Why I Built It

The core issue is workflow disruption. When you are managing social media, writing blog posts from a mobile device, or doing quick site updates, having to hop between different clunky apps just to resize or convert a photo is incredibly annoying. Many existing tools in the store were either loaded with intrusive ads, required subscriptions for basic batch processing, or had confusing interfaces. I wanted a local, on-device solution that respects user privacy, handles multiple files effortlessly, and simply gets out of the way. The goal was pure utility: open the app, select your photos, pick a format, and get it done.

The Tech Stack

For the foundation, I chose Kotlin and the native Android SDK. I wanted the app to be as lightweight as possible, so I avoided pulling in massive third-party C++ image processing frameworks. The UI was built using modern Android principles to ensure a clean, responsive layout that scales well across different screen sizes. Everything runs locally on the device, ensuring user data never leaves the phone.

Technical Challenges

Handling high-resolution images on a mobile device is notoriously memory-intensive. The single biggest hurdle was the dreaded OutOfMemoryError (OOM). Modern smartphone cameras capture massive files, and when a user selects fifty 12-megapixel photos for batch conversion, loading them directly into memory will crash the app instantly.

To solve this, I had to implement careful image subsampling and stream processing. Instead of loading the full image into a Bitmap, the app reads the image bounds first, calculates the optimal sample size based on the user's target dimensions, and only loads what is strictly necessary into memory.

Furthermore, the batch processing engine was built using Kotlin Coroutines. I needed a reliable way to handle the heavy lifting asynchronously without blocking the main UI thread. Creating a pipeline that reads, converts, compresses, and writes files concurrently—while keeping the phone responsive and managing thermal limits—was a delicate balancing act.

Lessons Learned

Memory management is unforgiving: You cannot rely on the JVM's garbage collection alone when dealing with Android Bitmaps. Explicitly managing memory, recycling objects when they are no longer needed, and utilizing InputStream and OutputStream directly instead of holding entire files in memory saved the project from stability issues.
UI feedback is crucial for long tasks: When processing a large batch of files, the user needs constant reassurance that the app hasn't frozen. Implementing a robust, granular progress tracker that smoothly communicates between background coroutines and the UI layer turned out to be more complex than expected, but absolutely necessary for a good user experience.
Not all formats are created equal: Tuning the compression algorithms took extensive testing. WebP, for instance, is highly efficient but handles transparency and compression artifacts slightly differently than a standard JPEG or PNG. Finding the sweet spot between file size reduction and acceptable visual quality required fine-tuning the native compression APIs.

Conclusion

Building an image utility sounds like a straightforward weekend project until you have to deal with the harsh realities of mobile memory constraints and concurrency. It served as a valuable learning experience in optimizing Android performance and building robust background processing pipelines.

If you ever find yourself frustrated by strict file size limits on web forms, or just need to quickly convert and compress images on the go, you can try out PhotoConvert: JPG PNG WebP GIF on Google Play. It is built to be a simple, reliable tool to solve exactly those frustrating formatting hurdles.

Rescuing Abandoned Repos: Building a Tool to Find Active GitHub Forks

Getinfo Toyou — Wed, 13 May 2026 14:32:27 +0000

The Open Source Graveyard Problem

If you've spent enough time building software, you know the sinking feeling. You're trying to debug an issue with a dependency, or you want to add a feature to an open-source library you rely on. You head over to its GitHub repository, only to see the dreaded "This repository has been archived" banner, or you notice the last commit was five years ago.

The project is dead. But in the open-source world, death is rarely final.

You click the "Forks" number, hoping someone, somewhere, has picked up the torch. And then you are presented with a list of 1,200 forks. Which one has the patch for that recent security vulnerability? Which one supports the latest version of Node or Python? Clicking through them one by one is an exercise in frustration. You usually end up looking at commit histories, comparing dates, and trying to figure out if the activity is real or just someone fixing a typo in the README.

That's the exact problem that drove me to build Forkfinder. I needed a way to cut through the noise and instantly identify the most active and well-maintained forks of any given GitHub repository.

Why I Built Forkfinder

The breaking point was a weekend side project. I was using a specialized data parsing library that had quietly been abandoned by its creator. I knew someone had to have updated it for the current runtime, but after 45 minutes of manual digging through a sea of inactive forks, I realized I was wasting time doing a job a machine should be doing.

Forkfinder is designed to do the heavy lifting. You paste in the original repository URL, and it analyzes the forks, ranking them based on meaningful metrics like recent commit activity, stars, and overall repository health. It gives you the maintained alternatives without the guesswork.

The Technical Challenges

Building a tool that analyzes GitHub repositories sounds straightforward until you hit the reality of API limits and data volume.

The primary challenge was efficiently gathering data on thousands of forks without getting rate-limited by the GitHub API. Querying every single fork of a massive project like torvalds/linux is not feasible in real-time. I had to implement a strategy to filter the initial list of forks down to candidates that showed at least some signs of life (like recent pushes) before doing a deep dive into commit histories.

Another hurdle was defining what "active" actually means. A fork with 500 commits that are just merges from upstream isn't necessarily more maintained than a fork with 10 commits that actually resolve outstanding issues. I had to refine the sorting algorithm to weigh recent independent commits more heavily than just raw commit volume.

The Tech Stack

To keep things lean and fast, I went with a modern web stack:

Frontend: React with Next.js for server-side rendering and fast initial loads.
Styling: Vanilla CSS structure keeping styles minimal and clean.
Backend/API: Node.js to handle the GitHub API interactions and sorting logic.
Data Fetching: The official GitHub GraphQL API. Using GraphQL instead of REST was a crucial decision—it allowed me to fetch exactly the data I needed (like repository details and recent commit timestamps) in a single request, drastically reducing overhead and helping manage rate limits.

Lessons Learned

The biggest takeaway from building Forkfinder is the importance of API strategy. When you're building a tool that relies on third-party data, your architecture has to revolve around their constraints. I spent more time optimizing GraphQL queries and handling rate-limit backoffs than I did building the user interface.

I also learned that open-source maintainers are incredibly resilient. It's inspiring to see how many abandoned projects are quietly kept alive by dedicated individuals in their own forks, just solving the problems in front of them.

Conclusion

If you're tired of wading through the open-source graveyard and manually comparing commit dates, give Forkfinder a try. It's a simple tool, but it solves a very specific, very annoying problem for developers.

I'm continually tweaking the ranking algorithm, so if you have ideas on what makes a fork truly "healthy," I'd love to hear them. Happy coding, and may your dependencies always be maintained.

Building a Zero-Friction Browser Game: The Tech Behind Echorunner

Getinfo Toyou — Mon, 11 May 2026 14:31:36 +0000

We've all been there. You have ten or fifteen minutes to kill while a heavy Docker build is compiling or a CI/CD pipeline is running its course. You just want to play a quick game to clear your head. But modern gaming often means sitting through a massive update, logging into multiple different launcher accounts, and playing through a mandatory tutorial just to get to the actual gameplay. The friction between wanting to play and actually playing is incredibly high.

I wanted something different. I wanted to build an experience that you could play instantly, without downloads, straight from your browser. That frustration with modern gaming overhead led me to create Echorunner.

Why I Built Echorunner

The goal was simple: create an accessible, instant-play arcade game for desktop and mobile browsers. No friction, just gameplay. But I also wanted a mechanic that felt fresh. Echorunner is an endless runner where your past self—your "ghost echo"—trails exactly three seconds behind you, destroying hazards in its path. It forces you to think spatially and temporally to survive, creating a unique loop of dodging obstacles while strategically placing your future ghost to clear the way.

Building a web game that runs smoothly across varying devices without native app performance requires some specific architectural choices.

The Tech Stack

I kept the stack lean to ensure fast load times and maximum compatibility.

HTML5 Canvas: The core rendering engine. It provides the raw drawing performance needed for a fast-paced arcade game without the overhead of heavy WebGL libraries.
Vanilla JavaScript: No bulky frontend frameworks here. For a game loop running at 60 frames per second, keeping garbage collection to a minimum and directly manipulating the state is crucial for a smooth experience.
Web Audio API: For low-latency sound effects, which are critical for timing, rhythm, and feedback in an action game.

Technical Challenges

1. The Ghost Mechanic

The defining feature—your echo trailing three seconds behind—was the trickiest part to implement efficiently. Initially, I was pushing the player's exact coordinates into an array every frame and reading from the beginning of that array three seconds later. At 60 FPS, that array grows rapidly, and continuously shifting it was causing performance hiccups on lower-end mobile devices.

The solution was implementing a circular buffer. Instead of a constantly expanding and shifting array, I allocate a fixed-size array based on the target framerate and the delay (e.g., 60 FPS * 3 seconds = 180 slots). An index pointer loops through this buffer, overwriting the oldest position with the newest one. Reading the echo's position is just a matter of looking at the current index. This memory-efficient approach smoothed out the framerate dramatically.

2. Procedural Obstacle Generation

To keep an endless runner engaging, the obstacles cannot be static. I built a procedural generation system that spawns hazards based on a difficulty curve that scales the longer you survive. However, ensuring that the generated paths are actually passable—especially factoring in the echo mechanic—required building a validation check before spawning a new chunk of the level. If a sequence is mathematically impassable, the algorithm regenerates it on the fly. Doing this without dropping frames required optimizing the generation logic to run within a couple of milliseconds.

3. Consistent Speed Across Refresh Rates

Browsers try to sync requestAnimationFrame to the monitor's refresh rate. If a player has a 144Hz monitor, the game loop runs more than twice as fast as on a standard 60Hz screen. If physics calculations are tied directly to frames, the game becomes unplayable at high refresh rates.

I had to decouple the rendering loop from the logic loop using a fixed timestep. The game logic updates in fixed increments based on actual elapsed time, regardless of how often the screen is drawn. This ensures that the speed of the runner and the obstacles remain consistent whether you are playing on a standard phone screen or a high-end gaming monitor.

Lessons Learned

Building Echorunner reinforced how powerful the modern web platform is. We don't always need an app store or a massive, multi-gigabyte engine to deliver a fun, performant experience.

It also reminded me that constraints breed creativity. By limiting myself to browser technologies and aiming for zero-friction access, I had to be meticulous about performance, memory management, and asset sizes. That tight focus ultimately resulted in a better, more accessible product.

Give It a Try

If you have a few minutes to spare and want to see how the circular buffer and fixed timestep feel in action, you can play Echorunner right in your browser. There is nothing to install, and no accounts are required.

Try it out here: https://echorunner.getinfotoyou.com

See how long you can survive using your own ghost to clear the path. I would love to hear your thoughts on the performance and mechanics in the comments!

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!