DEV Community: Getinfo Toyou

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!

Building DevConfessions: Tackling Imposter Syndrome with Anonymous Data

Getinfo Toyou — Thu, 09 Apr 2026 03:22:29 +0000

Have you ever pushed code on a Friday at 4:59 PM and spent the entire weekend sweating because you broke production? Or maybe you spent three days debugging a complex issue only to realize you were missing a single comma?

We've all been there. But in an industry that constantly celebrates "crushing it" and "10x engineers," talking about our failures can feel like career suicide. The pressure to always be the smartest person in the room breeds a culture of silent anxiety and rampant imposter syndrome.

I realized there was a missing piece in our community: a safe, judgment-free zone to vent, share our most embarrassing coding blunders, and realize that nobody actually knows what they are doing 100% of the time.

That's why I built DevConfessions — an Android app dedicated solely to anonymous confessions from the developer community.

The Problem It Solves

When we see other developers confessing that they still Google how to center a div after ten years of experience, or that they accidentally deleted an entire staging database, it does something profound: it humanizes our profession.

The core problem DevConfessions addresses isn't technical; it's psychological. It provides an outlet for the stress and absurdity of software engineering. It’s a place to read relatable, funny, and brutally honest developer humor, and maybe share a secret of your own, completely anonymously.

The Tech Stack

To get this off the ground quickly while ensuring a smooth user experience, I went with a modern Android stack:

Frontend: Kotlin and Jetpack Compose. Compose made building the UI incredibly fast, especially for a feed-based application where state management is key.
Backend & Database: Firebase Firestore. A NoSQL document database was perfect for storing simple text confessions and managing upvotes/downvotes.
Authentication: Firebase Anonymous Authentication. This was crucial. Users need to be able to interact without ever tying their identity to the app.

Technical Challenges

Building an anonymous app sounds simple until you realize you still have to manage abuse and ensure content quality.

1. Meaningful Anonymity vs. Spam:
How do you stop someone from spamming a database when they don't have an account? I had to implement rate limiting on the client side and write Cloud Functions to monitor write frequency from specific anonymous user IDs.

2. Content Moderation:
Since anyone can post anything, I needed a way to filter out genuinely malicious content or spam while keeping the raw, unfiltered nature of developer confessions. I integrated a basic keyword filtering system via a Cloud Function that triggers on document creation. If a post gets flagged by users enough times, it's automatically hidden pending manual review.

3. Randomizing the Feed:
Firestore isn't built to pull random documents out of the box. I had to implement a workaround involving random integer assignment to each document and querying based on ranges to ensure users saw a fresh, varied feed of confessions rather than just the most recent ones.

Lessons Learned

Building DevConfessions taught me a lot, not just about Jetpack Compose, but about how developers interact when the mask of professional networking is removed.

Keep it simple: The initial MVP had too many features. I stripped it back to just reading, posting, and reacting. The core value is the content, not complex features.
Anonymity breeds honesty: The sheer volume of relatable mistakes shared within the first few weeks proved that this outlet was needed.
Handling NoSQL: Structuring data for a social-feed style app in Firestore requires careful planning around data duplication to avoid excessive read costs.

Wrap Up

If you're feeling the weight of imposter syndrome, or if you just want to laugh at the collective struggles of our industry, you can check out the app. It's available on Google Play here: DevConfessions.

You can also find more of my projects over at getinfotoyou.com. Drop a confession—nobody will ever know it was you.

Handling 5+ Image Formats Natively on Android: Building PhotoConvert

Getinfo Toyou — Wed, 08 Apr 2026 11:20:24 +0000

Did you know that despite WebP images being 26% smaller in size compared to standard PNGs, a shocking number of web portals, government forms, and older software systems still completely reject them? This format fragmentation is a constant, quiet headache for everyday mobile users. A user downloads an image, tries to upload it, and gets hit with a rigid "format not supported" error.

Welcome to the messy reality of digital image formats.

Why I Built PhotoConvert

I noticed this friction happening frequently around me. When faced with an incompatible image format, most people instinctively search the web for "JPG to PNG converter" and upload their personal, sometimes sensitive, photos to ad-riddled, remote servers. This felt like a massive privacy risk and a wildly inefficient use of bandwidth, especially when modern smartphones have more than enough processing power to handle the task locally.

I wanted a tool that lived entirely on the device, worked completely offline, and didn't compromise on image quality. I needed it to handle bulk operations for photographers or designers who need to process dozens of files at once. That motivation led to the development of the PhotoConvert app.

The Tech Stack

For this project, I went native.

Language: Kotlin
Framework: Android SDK
Concurrency: Kotlin Coroutines and Flows
Storage: Scoped Storage API (to handle Android's modern, restrictive file access)

Technical Challenges

Building a local image processor sounds straightforward until you hit the physical limits of mobile hardware. Here are the main hurdles I had to overcome:

1. The Dreaded OutOfMemory (OOM) Exception
Decoding large images (like a 12-megapixel photo from a modern smartphone camera) to convert them into a different format takes a massive amount of RAM. If a user selects 20 high-resolution images for batch conversion, loading them all into memory simultaneously will instantly crash the app. I had to implement strict memory management, processing images sequentially and aggressively garbage-collecting bitmap objects the moment they were written to disk.

2. Navigating Format Quirks
Android's native Bitmap.CompressFormat handles JPG, PNG, and WebP reasonably well out of the box. However, handling older or more complex formats like BMP and GIF requires specific workarounds. Furthermore, converting from a format that supports transparency (like PNG) to one that doesn't (like JPG) often results in a solid black background where the transparent pixels used to be. To fix this, I had to programmatically draw a white canvas behind the image before compressing it to a JPG, ensuring the final image looked natural.

3. Taming Scoped Storage
Android's Scoped Storage rules mean apps can no longer just read and write anywhere on the device. Handling batch selection via the Storage Access Framework (SAF) and ensuring the app had the correct permissions to write the converted files back to the user's gallery without prompting them 50 individual times required careful orchestration of Android's MediaStore APIs.

4. Keeping the UI Responsive
Running heavy file I/O and bitmap compression on the main thread is a guaranteed way to freeze your app and trigger an Application Not Responding (ANR) dialog. I heavily utilized Kotlin Coroutines, specifically Dispatchers.IO, to push all the heavy lifting to background threads. Using Kotlin Flows allowed me to emit progress updates back to the UI seamlessly, giving users a real-time progress bar during batch conversions.

Lessons Learned

Never trust the file extension: Just because a file ends in .png doesn't mean it actually is one. I learned to always check the file's magic numbers (mime type) before attempting to decode it to prevent silent failures.
Offline-first builds trust: Users appreciate apps that don't require an internet connection for tasks that shouldn't need one. It builds immense trust, especially when handling personal media.
Coroutines are powerful, but cancellation is tricky: Managing the state when a user decides to hit the "Cancel" button halfway through a batch job of 100 images requires ensuring your coroutine scopes are properly structured so background work actually stops when requested.

Conclusion

Building PhotoConvert was a deep dive into the intricacies of Android file management and memory optimization. It reinforced the idea that sometimes the most useful tools are the ones that simply fix a small, recurring annoyance without adding unnecessary complexity or demanding an internet connection.

If you've ever been frustrated by format compatibility on your phone, you can give it a try. It handles JPG, PNG, WebP, GIF, and BMP natively on your device.

Check it out on Google Play or visit the project page. Let me know what you think!

Building a Browser-Based Image Optimizer to Skip the SaaS Fees

Getinfo Toyou — Tue, 07 Apr 2026 14:10:04 +0000

The Cost of Optimizing Images

As developers, we know that serving heavy, unoptimized images is a surefire way to hurt web performance and frustrate users on slower connections. It's one of the most effective wins for Core Web Vitals, yet it's often overlooked because integrating proper image compression into a daily workflow can be surprisingly tedious.

For a long time, my solution was either jumping through hoops with command-line tools that required context switching, or relying on various freemium SaaS products. The problem with those online services? They almost always come with strict limitations—file size caps, daily upload limits, or the eventual paywall for features that should be standard.

I didn't want to pay a monthly subscription just to occasionally crush a few PNGs for a blog post or a landing page. More importantly, I didn't want my files being uploaded to an unknown server just to be processed.

That frustration led me to build ImageSlim, a web application that compresses and resizes JPG, PNG, and WebP images entirely within the browser. No uploads, no hidden subscription fees, and no artificial limits holding back your workflow.

Why Browser-Based Makes Sense

The core differentiator I wanted for ImageSlim compared to commercial alternatives was privacy and speed through local processing. By leveraging modern web APIs, the actual heavy lifting of image compression happens right on your machine.

When you drag and drop an image into ImageSlim, it doesn't get sent to a backend queue. This means:

Zero waiting for uploads/downloads: Processing starts instantly.
Complete privacy: Your images never leave your device.
No server costs: Which means I can offer the tool without needing to charge for compute time.

The Tech Stack

To keep things lightweight and fast, I chose a straightforward stack:

Frontend Framework: React (with Vite for fast bundling)
Styling: Tailwind CSS (for rapid UI development)
Compression Engine: Browser-native canvas API and WebAssembly (Wasm) ports of popular compression libraries.

Using WebAssembly was the key to bringing server-grade compression algorithms directly to the client side, allowing for high-quality reduction without the server overhead.

Technical Challenges

Building a robust browser-based tool comes with its own set of hurdles.

1. Memory Management with Wasm

Processing large images directly in the browser can quickly eat up memory. I had to implement careful memory management when passing image data back and forth between JavaScript and the WebAssembly modules to prevent the browser tab from crashing, especially on mobile devices or older machines.

2. Balancing Quality and File Size

Different image formats require different approaches. Tuning the default settings for the encoders took quite a bit of trial and error. The goal was to find the sweet spot where the file size reduction was significant, but the visual degradation was imperceptible to the human eye. Providing users with a simple way to adjust this balance themselves, while seeing a real-time preview, was essential.

3. Handling Color Profiles

One unexpected challenge was dealing with color profiles (ICC profiles) embedded in JPEGs. Browsers don't always handle these consistently when drawing images to a <canvas> element for processing. Ensuring that the output image maintained the correct colors, especially for designers where color accuracy is critical, required extra attention to how the pixel data was extracted and re-encoded.

Lessons Learned

Building ImageSlim reinforced a few key ideas for me:

The browser is incredibly powerful. We often default to thinking we need a server for complex processing tasks. WebAssembly has fundamentally changed what's possible on the client side.
Simplicity wins. The initial version had too many advanced toggles. I realized most users just want to drop an image in, get a smaller file out, and move on. Hiding the complexity behind sensible defaults vastly improved the user experience.
Solving your own problems works. Sometimes, fixing a small friction point for yourself results in a practical tool that genuinely helps others skip the paid alternatives.

Try It Out

If you're tired of hitting paywalls or dealing with slow uploads just to optimize assets for your next project, give it a spin.

You can try it here: ImageSlim

It handles JPGs, PNGs, and WebPs, and lets you resize and compress without sacrificing visual quality. Let me know what you think or if you run into any edge cases with specific image files!

Building a SIP Calculator: Empowering Retail Investors with Accessible Financial Tools

Getinfo Toyou — Mon, 06 Apr 2026 06:46:13 +0000

If you've ever looked into investing, especially in markets like India, you've likely come across the term SIP (Systematic Investment Plan). It's a disciplined way to invest small amounts regularly into mutual funds. But for many new investors, visualizing the long-term impact of compound interest can be difficult. The math behind wealth creation is often abstract until you can see the numbers laid out in front of you.

That's exactly why I built the SIP Calculator at getinfotoyou.com. While there are plenty of financial tools out there, I wanted to create something straightforward, fast, and specifically tailored for retail investors who just want clear answers without navigating through cluttered, ad-heavy interfaces or complex financial jargon.

Who Benefits Most From This Tool?

The primary goal of this project was to help everyday retail investors take control of their financial planning. When you're just starting out, setting financial goals can feel overwhelming. By entering three simple metrics—your monthly investment amount, the expected return rate, and the investment tenure—users can instantly see their projected maturity amount and the total wealth gained over time.

This project is particularly useful for a few specific groups of people:

Beginner Investors: Those who need to see the practical magic of compounding over 10, 15, or 20 years to stay motivated and stick to their investment discipline.
Finance Enthusiasts: People who like to run multiple "what-if" scenarios. Whether they are planning for early retirement, saving for a down payment on a house, or funding a major life event, having a fast tool to test variables is invaluable.
Indian Users: The tool is designed with local context in mind. For users in India, understanding returns in familiar formats like Lakhs and Crores makes the data much more accessible and actionable than standard millions and billions.

The Tech Stack

For a utility tool like this, speed, reliability, and simplicity are the most important factors. I decided to build it as a lightweight, client-side Web App using:

React: For responsive state management. Since the calculations need to update in real-time as the user drags a slider or types an input, React's state handling made the UI feel snappy and reactive.
Vanilla CSS: I kept the styling custom and minimal. Relying on standard CSS ensures fast load times, semantic HTML, and a clean, accessible interface that works well on both desktop and mobile devices.
Vite: Used as the build tool for a fast, modern development experience and a highly optimized production build.

Technical Challenges

Building a financial calculator sounds simple on the surface—it's just a formula, right? However, it comes with a few interesting technical hurdles when you dive into the code:

Precision in Financial Math: JavaScript is notoriously quirky with floating-point math. Calculating compound interest over 360 months (30 years) requires careful handling of decimals to ensure the final numbers are accurate, trustworthy, and don't suffer from rounding errors at scale.
Dynamic Data Visualization: Presenting the data clearly was a major priority. I had to ensure that the visual representation of "Invested Amount" versus "Wealth Gained" updated smoothly. Managing the DOM efficiently was critical to avoid layout shifts or performance hiccups during rapid state changes.
Number Formatting: Displaying large numbers so they are easily readable is crucial. Implementing localized number formatting (specifically the Indian numbering system of Lakhs and Crores) was necessary to make the output intuitive for the primary target audience.

Lessons Learned

Building the SIP Calculator was a great exercise in focusing on user experience over feature bloat. The biggest takeaway for me was that financial tools don't need to be complex to be useful. In fact, removing friction and reducing the number of required inputs often leads to a significantly better user experience. Users just want the answer to their question as quickly as possible.

I also learned a lot about optimizing React components to prevent unnecessary re-renders, especially when dealing with continuous, high-frequency input from range sliders.

Try It Out

If you're currently planning your investments, trying to figure out your financial future, or just curious about how much a monthly contribution could grow over the next few decades, feel free to give it a spin.

You can check out the live project here: SIP Calculator

I'd love to hear your thoughts! Drop a comment if you have any feedback on how to improve the interface, handle the math differently, or add calculation features that would make it even more helpful for your own planning.

Building a Dead-Simple Tool to Catch Risky Hashtags Before You Post

Getinfo Toyou — Sun, 05 Apr 2026 03:34:27 +0000

If you manage social media accounts, you know the sinking feeling of realizing a seemingly innocent hashtag you just used has been hijacked by a bizarre internet subculture, or worse, quietly banned by the platform's algorithm. Suddenly, your carefully crafted post is suppressed, and your reach plummets.

I built HashtagSafety to solve exactly this problem, but my primary goal wasn't just to build an analyzer—it was to build something ridiculously simple to use. No logins, no complex dashboards, just instant answers.

Why Build This?

Social media managers and content creators are busy. The workflow for posting often involves juggling scheduling tools, asset libraries, and copy docs. Stopping to manually search every hashtag to see what recent content shows up is tedious.

I wanted a tool where you could paste your hashtag block, hit a button, and immediately get a red/yellow/green light on whether those tags are safe to use, protecting brands from accidental association with inappropriate content or the dreaded shadowban.

The Focus on Simplicity

When designing HashtagSafety, I focused entirely on removing friction.

Most marketing tools try to do everything—analytics, scheduling, keyword generation. This tool does one thing. You enter the tag, and it tells you if it's flagged or associated with known issues. The interface is just a text input and a result. This laser focus meant I could spend more time refining the backend logic rather than building out complex UI components for features nobody asked for.

The Tech Stack

Keeping the user experience simple often means the complexity lives in the backend. For this project, I went with a stack optimized for speed and straightforward development:

Frontend: React (Next.js) with Tailwind CSS. Next.js handles the routing and gives me the option for server-side rendering if I need better SEO on the results pages later. Tailwind kept styling fast and consistent without fighting custom CSS.
Backend: Node.js API routes within the Next.js app. This kept the architecture unified.
Data & Analysis: This is where the heavy lifting happens. The system relies on a combination of maintained databases of known banned tags and real-time checks against social platform APIs (where permitted) to assess the current context of a tag.
Hosting: Vercel, for zero-config deployments.

Technical Challenges

The biggest hurdle wasn't building the interface; it was ensuring the data remained accurate. Social platforms change their banned lists constantly, and tags move from safe to restricted overnight based on trending events.

Rate Limiting: Querying APIs to check tag status means running into rate limits fast. I had to implement intelligent caching. If someone checks #marketing, the system caches that result for a set period rather than asking the external platforms again five seconds later.
False Positives: Context matters. A tag might look safe but be used almost exclusively in restricted ways. Tuning the algorithm to balance safety without flagging every single popular tag requires ongoing adjustment.

Lessons Learned

The most valuable lesson was validating the "do one thing well" philosophy. By focusing strictly on safety checking rather than expanding into a full "hashtag generator" suite, I was able to launch much faster and solve a specific, painful problem for marketers.

I also learned that building an integration-heavy backend forces you to become very good at error handling. When third-party APIs fail or change their response structures, your app still needs to degrade gracefully and tell the user what's happening, rather than just throwing a blank screen.

Try It Out

If you're queueing up posts for the week and want to make sure your tags aren't going to get your content hidden, give it a try. It takes about two seconds.

You can check your tags at https://hashtagsafety.getinfotoyou.com.

I'm continuing to refine the detection algorithms, so if you notice any tags that are miscategorized, let me know in the comments!

Stop Googling "When is the next public holiday?" - Building HolidaySync

Getinfo Toyou — Thu, 02 Apr 2026 11:00:38 +0000

Have you ever tried coordinating a meeting with a remote team spread across three continents, only to realize half of them are out for a national holiday you've never heard of?

If you work remotely, manage a global team, or travel frequently, keeping track of international public holidays is usually a mess. You probably know the drill: you Google "public holidays in Spain 2024," land on a cluttered wiki page, try to cross-reference it with your calendar, and hope you got the dates right. Or worse, you build a massive, fragile spreadsheet that goes out of date the moment a country changes its observance rules.

I got tired of doing this the hard way. Searching for reliable, unified holiday data shouldn't require a master's degree in spreadsheet formulas. That's why I built HolidaySync.

The Problem: Doing It the Hard Way

Before HolidaySync, my workflow looked something like this:

Realize I need to schedule a project milestone with colleagues in India, Brazil, and the UK.
Open three separate browser tabs to check each country's national holidays.
Discover that some holidays vary by region or state.
Try to figure out if the holiday means a day off or just a cultural observance.
Manually block out dates on my calendar.

It was inefficient, prone to human error, and frankly, annoying. The raw data exists out there, but it's scattered across different governmental sites and third-party calendars, often in incompatible formats.

The Solution: HolidaySync

I wanted a single, clean interface where I could just type in a country name and instantly see an accurate, up-to-date list of its public holidays. No clutter, no ads, just the data.

HolidaySync is a web app designed to do exactly that. You can find public holidays for countries worldwide, plan your schedule, and sync those holidays across time zones without the usual friction. It's built specifically for remote workers, HR professionals, and anyone who needs to keep an eye on a global calendar.

The Tech Stack

To keep the application fast and responsive, I went with a modern JavaScript stack:

Frontend: React and Next.js. The static site generation capabilities of Next.js are perfect for serving calendar data quickly.
Styling: Tailwind CSS for a clean, minimal UI that looks good on both desktop and mobile.
Data Source: I integrated a reliable third-party REST API that aggregates global holiday data, ensuring the information stays current without me having to manually scrape governmental websites.
Hosting: Deployed on Vercel for seamless continuous integration and edge caching.

Technical Challenges

Building a calendar app sounds simple until you start dealing with the nuances of international dates.

The biggest hurdle was data normalization. Different countries report holidays in different formats. Some holidays are fixed dates (like December 25th), while others are calculated based on lunar cycles (like Diwali or Eid) or specific days of the week (like Thanksgiving in the US).

Handling these variations required writing robust utility functions to parse and format the incoming API data consistently. I also had to account for regional holidays—some days are only observed in specific states or provinces, which means the UI needed a way to display that granularity without overwhelming the user.

Time zones also added a layer of complexity. When a holiday starts at midnight in Tokyo, it's still the previous day in New York. Ensuring that the dates displayed correctly relative to the user's local time zone required careful use of JavaScript's Intl.DateTimeFormat and a healthy dose of testing.

Lessons Learned

Building HolidaySync taught me a lot about the importance of edge cases in data handling. You can't assume a date is just a date; context matters. It also reinforced the value of starting with a simple, focused problem. By narrowing the scope to just displaying accurate public holidays clearly, I was able to ship a useful tool much faster than if I had tried to build a full-blown scheduling suite.

Conclusion

If you're still relying on manual searches and spreadsheets to keep track of international days off, give the hard way a rest. Check out HolidaySync and see if it makes managing your global calendar a little bit easier.

I'm continuously working to add more features, so I'd love to hear your feedback on what would make it even more useful for your workflow!

I Built a Reading Time Calculator Because I Was Tired of Guessing

Getinfo Toyou — Wed, 01 Apr 2026 00:35:58 +0000

The Itch I Had to Scratch

Every time I finished writing a blog post, I'd do the same thing: paste it into a random word counter, then open a separate tab for a reading time estimator, then maybe copy it into Hemingway Editor for a readability check. Three tools. Three tabs. Same content.

That friction built up over months until I finally just... built one thing that does all of it.

That's how ReadMetric came to be.

Why This Problem Felt Worth Solving

Content creators obsess over SEO, formatting, and engagement — but reading time is one of those quiet signals that actually affects whether someone clicks "read more" on a platform like Medium or Dev.to. Studies have shown that readers self-select based on time commitment. Knowing your article is "4 min read" vs "12 min read" changes decisions — both for the writer and the reader.

I wanted a single tool that would tell me:

Estimated reading time
Word count
Character count
Sentence count
Readability score (Flesch-Kincaid)

All at once, instantly, as I type.

The Tech Stack

I kept it lean. ReadMetric is a client-side web app — no backend, no database, no auth.

Vanilla JavaScript for all the text parsing logic
HTML + CSS with a clean, distraction-free UI
Flesch-Kincaid algorithm implemented directly in JS for the readability score
Hosted as a static site

The decision to go fully client-side was intentional. There's no reason your text needs to leave your browser. No API calls, no data retention, no account needed. You paste, you get your stats, you move on.

Technical Challenges

1. Reading Time Isn't as Simple as `words / 200`

The common formula — divide word count by average reading speed (roughly 200–250 WPM) — gets you close, but it breaks down for technical content. Code snippets, URLs, and heavily formatted text all affect perceived reading time differently than prose.

I ended up adding a toggle for "technical content" that adjusts the WPM estimate downward to account for slower reading through code-heavy material. A small thing, but it makes the estimate more honest.

2. Sentence Counting Is Deceptively Hard

Split on . and you'll catch decimal numbers, abbreviations, and ellipses as sentence boundaries. I went through a few iterations before landing on a regex that handles the most common edge cases without being brittle.

const sentences = text.split(/[.!?]+\s/).filter(s => s.trim().length > 0);

Still not perfect — nothing is — but accurate enough for practical use.

3. Readability Scoring Requires Syllable Counting

The Flesch-Kincaid formula needs syllable counts, and English syllable counting in code is... an adventure. There's no perfect algorithmic solution without a full dictionary lookup. I used a heuristic approach based on vowel groupings and common suffix rules. It's about 85–90% accurate on typical prose, which is fine for a "is this readable?" gut check.

Lessons Learned

Scope creep is real, even on solo projects. I started with just reading time and word count. Then I added character count "real quick." Then sentence count. Then readability. Each addition was small, but collectively they doubled the initial build time.

Users care about simplicity. The first version had too many options. I stripped it back to the core stats and got better feedback almost immediately.

Client-side-only is underrated. Not every tool needs a server. The performance is instant, the privacy story is clean, and there's nothing to maintain on the backend.

Try It

If you write blog posts, documentation, newsletters, or any long-form content, give it a spin:

👉 https://readmetric.getinfotoyou.com

Paste in your draft and see what comes back. No signup, no install, no catch.

Feedback welcome — especially if you hit edge cases with the sentence counter. That thing has humbled me more than once.

Built by a solo dev at getinfotoyou.com — a small portfolio of practical tools for writers and developers.