Our Work

Race car setup is part-craft, part-science — and most of that craft lives in dog-eared notebooks, scattered spreadsheets, and WhatsApp screenshots passed around the pit lane. Engineers and drivers know what worked at a track last season, but pulling it back up at 7am on race day usually means flipping through pages or hunting through a phone gallery.

The founder came in with 15+ years in the V8 Supercar pit lane and a clear thesis: the knowledge that lives in elite race teams could be packaged for everyone from weekend club racers to seasoned pros — if the tool fit how race engineers actually think about a car.

Generic setup trackers had not worked. Racers did not trust them, the data models did not match real-world setup language, and there was no AI layer to turn raw setup numbers into "your front end is loose because of X — try Y."

We built Setup Genius as a multi-feature platform with the setup record at its core: every spring rate, damper click, alignment value, and tyre pressure stored against a track, session, and car. From there each module clips on — tyre inventory with usage and wear tracking, professional calculators for spring rates, roll centre and gear ratios, team sharing for crew alignment, and historical performance trends across sessions.

The AI setup assistant is the headline feature. It reads the current setup, the driver's stated problem ("understeer mid-corner", "no straight-line speed"), and the track context, and returns specific, racer-language recommendations. Underneath, that meant designing a domain model the AI could reason over reliably — not just storing numbers, but capturing how a setup actually behaves on track.

Built on Next.js with secure cloud storage so setups follow the team from the workshop to the trailer to the pit wall. Role-based access keeps driver, engineer, and crew on the same page without exposing IP between teams.

Setup Genius is live and being used by racers from weekend warriors through to professional teams. The AI assistant has become the daily-driver feature — racers describe a handling problem in plain language and get back targeted setup advice, which removes the "where do I even start" moment that used to eat 20 minutes of every session.

Tyre inventory tracking and the built-in engineering calculators have collapsed three or four separate tools into one workflow. Teams that were juggling a spreadsheet for tyres, a calculator app for spring rates, and a notebook for setups now run the whole session out of one platform.

The shared-setup feature has changed how teams communicate on race day — the engineer, driver, and crew chief all see the same numbers, so the conversation moves straight to "what should we change?" instead of "are we all looking at the same setup?".

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.