TEK

The problem

TEK started as my own product bet: a tool I wanted to exist and couldn't find done well. Because it's a product — not a client project — I owned every decision, from the data model to the pricing page, and lived with the consequences of each one.

That makes it the clearest demonstration of how I work: there was no one else to hand the hard parts to.

What I built

TEK is a full SaaS application, designed and shipped solo:

• Product surface — a typed Next.js App Router front end with server components, optimistic UI on the interactions that need it, and a design system that keeps the whole thing coherent as features pile up.
• Data & auth — a Postgres schema on Supabase with row-level security as the enforcement layer, not an afterthought. Auth, storage, and realtime where they earn their place.
• Billing — Stripe subscriptions wired through webhooks, with the upgrade, downgrade, and dunning paths actually handled rather than stubbed.
• Infrastructure — deployed on Vercel with AWS for the pieces that belong there, plus the CI/CD, environment, and observability glue that keeps a one-person product maintainable.

Outcome

TEK is live and in active use, on infrastructure I can reason about and extend without a rewrite. More important than any single feature: the architecture has held up as the product grew, which is the real test of decisions you make on day one.

Building my own product is also how I keep my freelance work honest — I'm shipping and maintaining the same kind of system I'm asking clients to trust me with.

What I took from it

• Row-level security from the first migration is far cheaper than retrofitting it.
• The billing edge cases are the product. Treating them as polish is how you lose revenue quietly.
• A small, consistent design system beats a feature-rich one nobody can navigate.