Why we build our own products
Most web agencies build for clients and stop there. We do that too — but we also build our own tools and products. It's how we stay sharp on the full product lifecycle, from idea to launch to iteration.
It's also honest marketing. It's easier to sell web development and AI automation when you've done it for yourself, shipped it publicly, and learned from real users.
The products: Caly, Forged, and MathFlow
Each of these started as a solution to a problem we noticed — either from client conversations, personal frustration, or a gap in what was available.
Caly is a scheduling and availability tool. Forged is a project scoping and proposal builder for service businesses. MathFlow is a step-by-step math problem solver built for students and tutors.
They're at different stages. Some are live, some are in beta. All of them have taught us something.
How we approach building: from problem to MVP
We don't start with design. We start with a problem statement: what's the user trying to do, what's getting in their way, and what's the minimum thing we can build to remove that friction?
Then we wireframe the core flow — just the happy path. No edge cases, no admin panel, no settings page. Just the thing that solves the problem.
- Problem statement: what's the actual pain?
- User: who has this problem, and how often?
- Core flow: what's the one thing the product needs to do?
- MVP scope: what's the smallest build that delivers the value?
- Stack decision: same stack we use for client work (Next.js, Sanity, Vercel)
- Launch: get something live and in front of real users fast
What's harder than expected
Client projects have a natural forcing function: deadlines and someone waiting on the other end. Internal products don't. It's easy to keep polishing, keep adding features, and never ship.
The hardest part of building for yourself is deciding what's done enough to put in front of real users. The answer is almost always: earlier than you're comfortable with.
Client project
- •Clear brief and deliverables
- •External deadline and accountability
- •Defined scope (usually)
- •Direct feedback from the client
- •Revenue on delivery
Internal product
- •You define the scope (risky)
- •No external deadline
- •Scope creep is self-inflicted
- •Feedback comes late (from real users)
- •Revenue comes later, if at all
What we've learned so far
Build the boring infrastructure first. Auth, billing, error handling — the stuff that isn't exciting but breaks everything if it's missing.
Don't build in isolation. Even sharing a rough version with five people early on changes the direction significantly. The sooner you get real feedback, the less you rebuild later.
Ship something, even if it's incomplete. A landing page with a waitlist teaches you more about demand than three months of building in private.
