A non-technical founder, a cross-border tax platform, and no engineering team

The client — confidential under NDA — understood cross-border taxation better than almost anyone in the room: years spent watching people overpay because no tool models two jurisdictions at once. Residency status, treaty relief, and the timing of income all interact, and every product on the market handles one country and stops there.

He had no technical team of his own, which usually forces a founder into one of two bad outcomes: endless agency quotes and a spec that keeps growing until the window closes, or a cheap build that collapses the first time real money passes through it. What he needed was a partner who would push back on the plan, not just execute it.

There was no engineering team to scope, design, or build a genuinely differentiated product, and the idea itself was harder than it looked: modeling two jurisdictions interacting at once, when every competitor stopped at one.

Before writing any code, we went through every product in the space feature by feature against his wishlist — what each one handled, where it quietly gave up, what sat behind a paywall, and where its users complained loudest. Several features he'd assumed were table stakes turned out to be commodity: every competitor already had them, and none were a reason for a user to switch. We cut those from v1 and put the engineering time into the features that had no real market equivalent instead.

We designed before we built. Low-fidelity Figma wireframes came first — fast and disposable, so any disagreement about direction happens when a change costs an hour, not a week — followed by high-fidelity design, and only then code. A non-technical founder can review a screen in a way he can't review an API, so he clicked through and signed off on the entire product before a line of code was written. That sequencing is the reason there was no mid-build rebuild and four weeks was actually achievable.

Every architecture decision was made as if the product would still be running in three years, not just through launch. Data lives on Postgres via Supabase — tax logic is relational and audit-sensitive, and the product needs to reconstruct why a number came out the way it did months later, so row-level security and a managed database from day one mattered more than moving fast and figuring it out later. Compute runs on Cloudflare Workers at the edge, because tax calculation is bursty and latency-sensitive and this product's users are spread across jurisdictions by definition — edge compute made it feel fast everywhere without paying for regional infrastructure the product hadn't earned yet. Azure sits alongside it for a specific infrastructure and data-residency need. The application layer is Next.js and Node, chosen deliberately rather than for novelty — the plan from week one was for his own engineers to eventually take this over, and an exotic stack just makes a product hard to hire for and hard to hand off.

In full: design in Figma and Adobe XD; the build in Next.js, Node.js, PostgreSQL, Supabase and OpenAI; infrastructure on Cloudflare Workers, the wider Cloudflare platform, and Azure.

The tax numbers themselves are computed deterministically — a language model never decides what someone owes. We used AI only where it's genuinely better than plain code: interpreting unstructured input, turning a completed calculation into a plain-English explanation the user could actually act on, and cutting down manual data entry between a user and an answer. In a product where the output is a financial figure a user relies on, the line between 'generated' and 'calculated' has to be absolute, and we drew it before anything was built rather than discovering it was blurry after launch.

The four-week timeline is exactly where builds like this usually go wrong — speed gets bought by writing code that has to be thrown away the moment the product becomes real. The hard part was refusing to take that shortcut: running the full competitive-scoping and design-first process on a genuinely tight clock, and making irreversible architecture calls — the data layer, the edge infrastructure, the stack itself — fast enough to still hit four weeks, and correctly enough that none of them had to be unwound later.

The product went live on schedule — not a prototype or a clickable demo, the real thing, with real users and real numbers running through it from day one.

We kept running the platform in production after launch — monitoring, fixes, dependency updates, the unglamorous work of keeping a live financial product healthy. When something broke, it was our problem, at our cost, and he found out from us rather than from a user.

He hired his own engineering team, which was always the plan — the stack decisions from week one were made with that hire in mind. We stayed on until that team was hired and up to speed, then handed over the codebase and stepped back. For a founder without a technical team, that phase — someone who answers the phone once the thing they built is carrying a user's tax liability — is the whole ballgame. The goal was never to become a permanent line item on his budget; it was to get him to the point where he didn't need us, and then actually leave.