DEV Community

DevToolsmith
DevToolsmith

Posted on

5 Dev Tools I Built in 4 Months — What Worked, What Flopped

#webdev #indiehackers #startup #saas

5 Dev Tools I Built in 4 Months — What Worked, What Flopped

A solo founder's retrospective on shipping a compact SaaS portfolio in 2026: real architecture decisions, painful UX lessons, and what I'd do differently next time.

I'm a solo founder. Between January and May 2026, I shipped five production dev tools across five separate .dev domains. Each one solves a narrow, expensive problem — accessibility audits, compliance scans, failed-payment recovery, PDF extraction, screenshot capture.

This post is the unfiltered retrospective. What landed, what didn't, what I'd build again, and what I'd skip.

The five products

Product Domain Problem it solves
CompliPilot complipilot.dev EU AI Act compliance scanning (200+ automated checks for AI systems)
FixMyWeb fixmyweb.dev WCAG 2.1 accessibility scanner (201 checks in 60s + PDF export)
PaymentRescue paymentrescue.dev Stripe failed-payment recovery (30-50% recovery via smart dunning)
ParseFlow parseflow.dev PDF / invoice → structured JSON API (no ML training required)
CaptureAPI captureapi.dev Screenshot + PDF + OG image REST API (200 free/month)

All five run on Next.js (App Router) + Vercel Fluid Compute + Upstash Redis + Stripe + Brevo. Total monthly infra cost across all five: roughly the price of a single dinner out.

What worked

1. Brutally narrow scope at launch

Each tool ships with exactly one core workflow and three differentiators. No dashboards. No team management. No "and also we do X." This kept the JTBD (jobs-to-be-done) crystal clear in every landing-page hero.

Example: PaymentRescue does only failed-payment recovery via Stripe webhook + dunning sequence. It does not do invoicing, subscription analytics, or churn modeling. People reading the homepage in 5 seconds know exactly whether it's for them.

2. Sharing infrastructure across the portfolio

All five SaaS share:

  • One Brevo account (5 verified senders, one per domain)
  • One Upstash Redis instance (namespaced keys: cpilot:, fmw:, pre:, pfl:, cap:)
  • One Stripe account (5 products, 5 webhooks, distinct currencies handled)
  • One Vercel team (5 projects, shared env vars where sensible)
  • One identical redeem + api/v1/* pattern in code

This means a bug fix in one tool — like the recent dedup-TTL pattern fix in lib/email.ts — can be back-ported to the other four in 30 minutes. Boring uniformity is leverage.

3. Customer reviews collected from day 7

I baked a review-request hook into every redeem flow: 7 days after first paid use, an Upstash ZSET schedules a Brevo email asking for honest feedback (1 click = NPS score; reply for full review).

Result: 5 verified five-star reviews on external review platforms within 30 days of launching the first product. Reviews don't just convert future buyers — they unlock distribution channels that require social proof.

4. Zero-marketing launch via curated marketplaces

For B2B dev tools, paid acquisition is brutal (CPCs $15-50 in this space). What worked instead: getting onto curated SaaS marketplaces that already aggregate the buyer audience. Within 60 days, the portfolio generated meaningful revenue with literally zero paid ads.

The mechanics: package each tool with screenshots, comparison tables, feature image, FAQ, and reviews → submit to 2-3 vetted marketplaces → let them do the distribution. The work is upfront; the channel runs itself afterward.

5. Free tier as a conversion gateway, not a charity

CaptureAPI gives 200 screenshots/month forever, no credit card. FixMyWeb runs one free scan per visitor per month. ParseFlow processes 100 free pages/month.

This is not generosity. It's a measurement system: I see exactly which use cases bring people in, which features they use most, and which moment they hit the wall and upgrade. Conversion rate from free → paid sits around 4-6%, well above industry averages for cold traffic.

What flopped

1. Over-investing in landing-page polish before validating the funnel

My first product (FixMyWeb) had 6 weeks of UI polish before I had a single paying user. Subsequent products shipped with a basic homepage + functional redeem flow, then iterated based on real user behavior. Time-to-first-paying-customer dropped from 38 days to 4 days.

2. Building white-label PDFs before anyone asked

I assumed agencies would want white-label exports. Built a sophisticated PDF templating system in two products. Demand: roughly zero, because most agencies are happy to forward the standard branded PDF with their own cover letter. Two weeks of work that's still sitting unused.

3. Internationalization too early

I added 7-language support to one tool at launch. Result: 4% of traffic was non-English, conversion from non-English visitors was below 1%, and translation maintenance cost meaningful time. Ship English first. Add languages when one specific market crosses 10% of revenue, not before.

4. Trying to "look like a team"

Early landing pages had cute team illustrations and "we" copy. After switching to honest solo-founder voice (real first name, real photo, real story), conversion rates went up across all five products. Buyers in this segment prefer transparency to enterprise theatre.

5. Building features without measuring impact

PaymentRescue got 4 different dunning email templates in the first month. Three of them have never been A/B tested against each other. They're code debt, not features.

What I'd do differently

  1. Ship the redeem flow before the landing page. The redeem/checkout/onboarding flow is the conversion engine. Polish that first, hero copy second.

  2. Build the review-request automation as part of the initial product scaffold. Reviews compound; the cost of adding them later (refactoring email service, schema migrations, customer outreach) is much higher than building them at day zero.

  3. Stop adding features until I have an A/B test infrastructure. GrowthBook on Vercel takes 30 minutes to set up. Every feature shipped without measurement is a hypothesis you'll never get evidence on.

  4. Document the operational runbook in code, not in memory. I now have one RUNBOOK.md per SaaS in the repo root. When something breaks at 3am, future-me will thank present-me.

  5. Pick the LTD marketplace strategy on day 1, not month 3. Pricing model affects every part of the funnel. Deciding to support both subscription and lifetime deal after launch meant re-engineering the Stripe schema, webhooks, dedup logic, and user model. A weekend of work became three weeks.

The unsexy truth

The biggest unlock wasn't a clever technical decision or a viral marketing channel. It was shipping one boring, narrow-scoped tool after another, then connecting them with shared infrastructure.

Five separate products at $19-$49/month each can outperform one big product at $199/month, because the buying decision at each price point is independent. A freelance accessibility consultant might buy FixMyWeb for $9/month and never need the other four. A fintech CTO might buy ParseFlow for $49/month and never know CaptureAPI exists.

The portfolio model also gives you optionality: if one tool flops, the other four still pay for the infra. If one takes off, you've already validated the model and can double down.

Try them

If you want to see the actual products:

If any of these solve a problem you're hitting, I'd love to hear what works and what doesn't — solo founders live and die by direct user feedback.

Happy shipping.

Top comments (0)