Our Work

A two-person fintech startup had raised a small friends-and-family round and needed to turn their validated idea into a shippable product — fast. They had a detailed spec, a design file in Figma, and a hard deadline tied to a pilot with three paying customers. What they did not have was engineering capacity.

The product needed multi-tenancy from day one: each company that signed up needed isolated data, role-based permissions, and the ability to invite team members. They also needed Stripe billing wired up before the pilot, because free trials were not part of the deal.

They had tried hiring a freelancer who disappeared after two weeks with a partially-working prototype. They needed someone who could take ownership of the full technical execution, not just write code to a ticket.

We started with a two-day architecture session to nail the data model and auth strategy before writing any application code. Multi-tenancy via a tenant_id foreign key pattern on every table, combined with Supabase row-level security policies, gave us data isolation without a complex microservices setup.

Authentication was built on Supabase Auth with custom middleware for role checking (owner, admin, member). The billing integration used Stripe Checkout for subscriptions and Stripe webhooks to provision/deprovision seats in real time. We set up a CI/CD pipeline on day three so every push was tested and deployed to a staging environment automatically.

The frontend was a Next.js app router project with a shared component library built on shadcn/ui. We wrote enough tests to cover the billing and permissions logic — the two areas where bugs would have been most damaging to the pilot relationship.

We shipped the product in six weeks. All three pilot customers were onboarded on day one of the pilot period. The founders were able to run the demo calls themselves without needing us on standby because the product was stable.

After the pilot, both founders reported that investor confidence had increased significantly — having a production-grade product rather than a prototype changed how those conversations went. The product has been running in production without incident since launch.

The handover documentation meant the founders could onboard a part-time developer to handle minor changes without needing to come back to us for every small request.

A bootstrapped SaaS founder had been running a project management tool for small construction companies for two years. The product had paying customers, solid retention, and a clear roadmap of features their customers kept asking for. The problem was time.

Every week, some portion of the founder's attention was pulled away from sales calls and customer conversations to deal with a broken report export, a user who could not log in, or a dependency that had gone out of date and was causing warnings in the console. None of it was catastrophic, but all of it was constant.

They had tried hiring a part-time developer but the onboarding cost was high and the person had left after four months. They needed a reliable engineering presence that did not require them to manage someone week to week.

We started with a two-week onboarding period to get familiar with the codebase, document the parts that were not documented, and set up proper error monitoring with Sentry. That first look also surfaced three security issues that needed fixing before we could confidently add new features — an exposed API route that did not check authentication, outdated packages with known CVEs, and a missing rate limit on the login endpoint.

Once the foundation was stable, the engagement settled into a monthly cadence: the founder would send through a prioritised list of bugs and feature requests, we would scope them, build them, test them, and deploy them. Response time for production-breaking bugs was same-day. Non-urgent requests were batched into the monthly cycle.

After six months we added automated dependency updates via Renovate with a weekly review window, which removed the need for manual patch management entirely.

Within the first three months, the founder reported that their week had changed meaningfully — the technical interruptions that had been a regular drain on their attention had largely stopped. They were spending more time on customer calls and less time explaining to users why something was broken.

Seven new features shipped across the first year of the engagement — more than had shipped in the previous twelve months combined. The founder attributed this partly to having reliable engineering capacity and partly to not being mentally occupied with firefighting.

The three security issues fixed in onboarding were particularly significant — one of them was in the authentication flow, and the founder had not known it existed.