17 Products in 24 Months: Honest Lessons from Building Codmaker

In 24 months Codmaker shipped 17 mobile and web apps — AI identifiers, productivity tools, Arabic games, Islamic apps, and developer utilities — built solo on a React Native and Next.js stack. This is the post we wish someone had written before we started: what worked, what we would burn, and what to do instead.

Codmaker is an independent product lab. We do not take clients. Every product on the site is one of ours. The goal was always to ship enough to find the ones that matter, learn from real users, and run a calm operation that did not depend on a single product surviving.

After 24 months the math reads: 17 products, 5 categories, 7 live in stores or on the web, 17 deep-dive engineering articles, one engineer. The interesting part is not the count. It is what shipping 17 in a row taught us about which lessons hold and which conventional wisdom is wrong.

Here is the unfiltered breakdown of what 24 months of solo product building actually looks like — not the polished version, the operational one.

The seven live products do almost all of the work. The other ten keep the lab learning and serve as testbeds for new patterns, but they do not carry revenue or downloads weight. That ratio — roughly 40% in market, 60% in build or pre-launch — has been stable across the 24 months and is probably structural for a solo lab. The constraint is attention, not effort.

• 17 total products across iOS, Android, and web
• 13 mobile apps (React Native + Expo)
• 4 web apps (Next.js)
• 7 currently live in stores or on production URLs
• 10 in active development or pre-submission state
• 5 product categories: AI Identification, Productivity, Games & Trivia, Islamic Apps, Developer Tools
• 17 long-form engineering articles published alongside
• 0 clients, 0 outside investors, 1 engineer

The first lesson is the cliché everyone says and almost nobody actually does.

PlantDoc's first version had three bugs and one usability disaster in the first week. The camera flickered on iOS 17. The identification confidence threshold was wrong. The pet-safety field returned for non-toxic plants. Real users found all three in two days. We fixed them in three. None would have surfaced from another month of pre-launch testing — they required real iPhones, real users, real impatience.

The math is brutal: a month of polishing before launch is a month of zero feedback. A week of polishing followed by a week of fixes-after-launch produces a better product, faster. We have not yet had a product that launched broken enough to materially hurt us. We have had several products that died in pre-launch polish — perfected and never shipped.

What 'ready' actually means for us now: the happy path works, the obvious failure mode shows a useful error, and one core flow has been tested on three real devices. That is it. Everything else gets fixed after launch with the benefit of feedback you cannot manufacture.

We use React Native for mobile and Next.js for web. Same stack on product #1, same stack on product #17. We have not switched. We will not switch.

This sounds obvious. It is not. Every six months a new framework appears with better DX or marginally better performance. Twitter is full of arguments. Every switch costs roughly 200-400 hours of relearning, retooling, and rebuilding shared infrastructure. Over 24 months, two stack switches would have erased 800 hours — about four months of shipping time.

The right time to switch frameworks is when your current one is actively blocking a product you must ship. None of ours did. React Native and Next.js ship products. The marginal benefit of switching to Flutter, SwiftUI, or whichever framework is currently winning was nowhere close to the cost.

This applies inside the stack too. We use the same auth pattern, same state management, same backend setup across products. That repetition is not boring — it is the reason we can spin up product #18 in a week instead of a month. Templates, shared infrastructure, and one good way to do each common thing.

This is the hardest lesson. The point of shipping 17 products is not to have 17 successful products. It is to find the one to three that actually carry the lab.

AdMetric Pro is the most natural commercial fit — paid app developers with money looking for AdMob analytics on the go. PlantDoc finds a different audience: casual gardeners wanting a 5-second answer. Tahadi Alkalimat reached an underserved Arabic-speaking word game audience. Each works in different ways. The other live products are still finding their audiences, and several of them will not.

This is the standard power-law distribution every indie portfolio shows up to. We knew it intellectually before we started. Watching it happen still surprised us — how skewed the distribution actually is, how early it shows up, and how often we caught ourselves treating the long-tail products with the same investment as the winners.

The discipline we have forced on ourselves: every quarter, look at active users and revenue per product, then reallocate dev time toward the ones above the median. Brutal but necessary. Carrying 17 products with equal love is a path to all of them being mediocre.

We started 2024 assuming AI would be a core feature in every app. By 2026 we would say something more specific: AI changed one specific category brutally well — vision identification — and added marginal value almost everywhere else.

PlantDoc, Fish Identifier, and SeedAI are direct beneficiaries. Without LLM vision, none of those apps work. The user value is concrete: instant species ID from any photo, plus a follow-up chat for context. That category was unreachable to a solo dev before 2023. Now three of our products live there because the cost-to-build collapsed.

Outside vision identification, AI feels less like a feature and more like a slightly better tool in the toolbox. The AI chat in our Pro tiers gets used, but it is not why anyone subscribes. The 'AI-everything' framing turned out to be Twitter noise. The 'pick one capability AI does brilliantly and build around it' framing turned out to be the playbook.

Practically: we still use AI tools constantly during development. Cursor and Claude Code shave hours per day. What changed is the assumption that AI must be visible in the product. It is invisible in 14 of our 17 products and that is correct. AI as engineering leverage is real. AI as a product feature is real only when the user value is concrete and could not exist otherwise.

The expensive lesson: building the product is the cheap part. Distribution is where the bill arrives.

For mobile apps, the App Store is the entire distribution channel for most indie devs. ASO (App Store Optimization) and paid acquisition were not skills we had at the start. We learned ASO by losing months of organic traffic to bad screenshots and weak keywords. We learned paid acquisition by running campaigns that did not pay back. Both lessons came with real opportunity cost — months where the products existed but no one was finding them.

What we would do differently: invest in ASO and screenshot design before the first listing goes live. Bad first-day metadata is sticky — Apple's algorithm weighs early signals heavily, and a soft launch with weak metadata trains the algorithm against you. Spend a week on listing copy and screenshot variants. Run them past 3-5 people in your target audience before submitting.

For web products, distribution is SEO plus content plus sharing. We learned this stack later than we should have. The first six months of writing the engineering blog were largely wasted on topics with no search intent. The strategic SEO doc we now run from would have saved most of that time. Strategic content with measurable intent beats prolific content with vibes.

Compressed retrospective — the time-sinks we would cut on a do-over. Each of these cost us at least two weeks across the 24 months. Combined they probably cost us a quarter.

• Building a custom design system before product #5 — ship with off-the-shelf primitives, extract patterns when they actually repeat across products
• Tracking analytics on day one — the dashboards we built for week-one MAU on apps with 30 weekly users were elaborate procrastination
• Adding low-traffic language translations — German and Italian on a product with 200 monthly users in those languages was a waste. Ship the top 2 languages, add more when product-market fit is real
• Custom backends when Supabase or Firebase would work — we spent weeks on Postgres + auth + email infrastructure for products that never needed the flexibility
• Acting on feature requests from low-LTV users — power users with weak commercial intent generate the loudest feedback. Filter aggressively
• Experimenting with frameworks we had not shipped with — every framework experiment cost weeks. Pick a stack on product #1, stay there through product #17

Each winner solved a specific problem for a specific audience with low competition and clear willingness to pay or engage. The pattern is consistent enough that it is now the first filter we apply to any new product idea.

AdMetric Pro is the runaway commercial success. It solves a specific, painful problem (AdMob revenue tracking on mobile) for a specific buyer (indie app developers) who already knows the problem and has money. The buyer arrived with intent. We just had to build something good and make it discoverable. Discoverability still took work — but the demand side was settled.

PlantDoc found product-market fit on the 'free with simple identification' side. The buyer is a casual gardener who wants an answer in 5 seconds. We optimized the first-tap-to-result flow obsessively. That speed is the moat — every plant ID competitor is slower by a fraction of a second, and that fraction matters in casual mobile use.

Tahadi Alkalimat (the Arabic crossword game) found a real audience in the Arabic-speaking world by being the first quality Arabic-first word game on iOS at the time we launched. The category was empty. The audience was waiting. We did not invent demand — we filled an obvious gap.

Honest accounting of what has not worked. None of these are dead — they are still live or recoverable — but they have not hit traction, and the reasons are now obvious in hindsight.

Web Tools and LifeCost live in a commodity category with hundreds of identical free alternatives. Without a defining hook or strong SEO strategy, they struggle to find search-driven traffic. We started them for personal interest, not strategic fit. Lesson: commodity tools in commodity categories need a hook to escape commodity competition. Building one more JSON formatter is not enough.

Some of the Islamic apps have not found their audience yet. The market exists — it is huge — but App Store discoverability in non-English categories requires native ASO knowledge we did not have at the time. We are learning it now, and revisiting the listings. The product quality is fine. The distribution work is unfinished.

Word Builder shipped without a clear hook. It is a fine word game, but 'fine' does not survive in a crowded App Store. Either the game needs a defining mechanic users cannot find elsewhere, or it dies quietly. We did not earn enough differentiation to compete in the category.

The mistakes here were not technical. The products work. The mistakes were category-selection and distribution. We started products without asking the single most important question: is there an underserved audience here, and can we reach them through a channel we already understand? That question gates everything else now.

For the next 12 months: fewer products, deeper investment per product. The 24-month sprint produced enough portfolio breadth. The next 12 are about depth.

The lab itself is the meta-product. We optimize it the way we optimize the apps: ship, learn, refactor, repeat. The math has changed enough that the next 24 months will look different from the first — but the operating model is the same. Independent, owner-operated, no clients, no investors, calm.

• Stop launching new categories — double down on AI Identification (proven), Productivity (proven via AdMetric Pro), and one Islamic flagship
• Invest in ASO and content distribution for existing live products before launching anything new
• Ship 4-6 products in 2026 instead of 8-10 — each gets 2x the polish, 2x the launch effort, 2x the marketing budget
• Write the playbooks we now run from — pillar content on running a digital product lab is on the roadmap, this article is the first piece
• Publish per-product case studies for the live apps — each one a worked example of the pattern that made it win or stall

Quick answers to questions we get from indie hackers and solo developers considering the same path.

• How can one engineer ship 17 products in 24 months? Stack discipline (no framework switching), template reuse (auth, payments, analytics shared across products), and shipping at the 'happy path works' threshold instead of the 'everything polished' threshold. The pace is steady, not heroic.
• How much money does Codmaker make? We do not share product-level revenue publicly yet. An annual transparency report is on the roadmap. What we will say: AdMetric Pro is the meaningful revenue driver, and the lab covers its costs and pays the founder.
• Why not raise money and scale faster? Outside investment changes the operating model. Investors want growth on a timeline; we want optionality. The lab's compounding advantage is that we can pick projects on intrinsic interest, not investor pressure. Different game, different rules.
• Should I start a digital product lab? Depends on what you optimize for. If you want maximum income per hour, freelance or join a strong company. If you want optionality, learning, and ownership of multiple bets — a lab works. The first 6-12 months are financially worse than freelancing. The compounding starts later.
• What was the worst product decision? Building Web Tools (commodity utility category) and Word Builder (no defining mechanic). Both were 'interesting to build' but lacked clear audience pull. We will not start a product now without asking: is there an underserved audience here, and can we reach them?
• How do you decide what to build next? Three filters: (1) is there a specific audience with a specific painful problem, (2) can we reach them through a channel we already understand, and (3) does the product use the stack we are already shipping with. New stack OR new channel OR new audience type = pass.

More from the lab on the patterns, stack, and tooling that shipped these 17 products.

• The Indie Developer's AI Stack for Shipping Products 2026 — the full toolchain breakdown: /blog/indie-developer-ai-stack-2026
• AI Code Completion Tools Compared 2026 — what we use to ship faster: /blog/ai-code-completion-tools-compared-2026
• n8n Workflow Automation: Build, Scale, Self-Host — how we automate around 17 products: /blog/n8n-workflow-automation-complete-guide
• Browse the portfolio — 17 products, 5 categories, 7 live: /portfolio
• About Codmaker — how the lab actually runs: /about