Back to blog

Why We Build Our Own Products Before Taking Client Work

February 15, 20264 min read
founderphilosophyindie

Why We Build Our Own Products Before Taking Client Work

Most freelancers and agencies pitch what they can do. Decks, case studies from other people's projects, testimonials that could be from anyone. We wanted something different. We wanted to show what we've done.

The Portfolio Problem

When you're starting out as a developer, you have a chicken-and-egg problem. Clients want to see previous work. But you need clients to have previous work. The standard advice is to build "portfolio projects" or contribute to open source.

We did neither.

We built real products. Products that have real users, real payment processing, real infrastructure. Products we use ourselves. Products that make money (some of them, anyway).

Why This Works

When a potential client asks "can you build a SaaS with Stripe integration?", we don't say "yes, we've done it before for a client." We say "here's ProvenTools.net. 118,000+ ideas indexed, Stripe subscriptions, Supabase auth, deployed on Vercel. We built every line of it."

That hits different. There's no ambiguity. No "well, we worked on a team that built something similar." It's all ours, it's all live, and you can go try it right now.

Three reasons this beats traditional portfolios:

  • It proves full-stack ownership. Client work usually involves teams. Our products prove we can handle everything from database schema to payment webhooks to deployment.
  • It shows taste. Anyone can follow a tutorial. Building a product that people actually use requires understanding users, not just code.
  • It's always available. No NDAs. No "we can't show you that project." Everything is public, live, and clickable.

The Compounding Effect

Every product we build teaches us something new. ProvenTools taught us subscription billing. BacklinkRocket taught us SEO at scale. Clyrify taught us iOS App Store optimization. PricePatch taught us the App Store Connect API. StillHere taught us cross-platform push notifications with Expo.

Each product becomes a reference architecture for client work. "You want CloudKit sync in your iOS app? Here's how we did it in Clyrify. Let us show you."

The Honest Part

Not all our products are hits. Some have zero users. Some make $3/month. That's fine. The point isn't that everything we build prints money. The point is that everything we build is real. Real code, real deployment, real maintenance.

And when a client sees 21+ shipped products across web, iOS, macOS, and desktop, the conversation shifts from "can you do this?" to "when can you start?"

The Takeaway

If you're a freelance developer or thinking about consulting: build something first. Not a tutorial project. Not a clone. Build something you'd actually use. Put it on a domain. Charge money for it (even if nobody pays). Maintain it.

That one product will close more deals than any portfolio page ever will.