How ServoSimple was built, a case study in shipping a real SaaS solo

ServoSimple went from idea to paying petrol stations in twelve weeks, built by one senior developer with AI assistance.

I run three AU petrol stations. The rostering software I was paying for was costing me five thousand dollars a year, did not handle PIN-based clock-in, and could not tell me at a glance which staff member was about to roll into overtime on Saturday afternoon. The same was true at almost every other AU service station I knew. The category leader was a 2009-era Windows app being sold for nineteen ninety-nine a month per site, and the only competing option was a fifty-thousand-dollar custom build from a Sydney agency that took nine months to deliver.

There was a gap. The gap was bigger than rostering. It was every operational system inside an Australian petrol station, glued together with spreadsheets and Slack messages. So I built ServoSimple.

This post is the build log. The stack we chose and why. What shipped in the first four sprints. What we got wrong. What it cost. And what it means for any AU SMB owner thinking about commissioning a custom build right now.

The problem nobody was solving

Petrol stations are the most under-served vertical in AU SMB software. Roughly seven thousand sites across Australia, each one running a daily operation with employees, fuel inventory, cash handling, compliance, drive-offs, EFTPOS, loyalty, and ATO obligations. None of the available SaaS tools handle even half of that workflow well.

The most common stack I saw walking into ten sites in three months:

• Rostering in a spreadsheet, sometimes shared via WhatsApp
• Timesheets on paper, transcribed by the manager on Sunday night
• Drive-off logs in a notebook
• Fuel deliveries reconciled by hand against supplier statements
• Compliance documents stored in a folder marked "ATO" that nobody opens until BAS time
• Half the sites had no formal handover process between shifts

The collective time cost on a single site is roughly twelve hours a week of owner-operator admin. At an opportunity cost of forty dollars an hour, that is nearly twenty-five thousand dollars per year per site, plus the rework when something gets missed.

The question was not "should this be software" but "why does this software not exist yet."

The stack and why we chose it

ServoSimple is a Next.js 16 application running on Vercel, with Supabase as the database and auth layer, Stripe for billing, Resend for transactional email, and a thin client-side state layer using React Server Components throughout. PIN clock-in uses a custom physical-keypad UI built for the forecourt context, designed to work with cold or fuel-covered fingers on a touchscreen mounted next to the till.

We picked this stack for three reasons.

Reason one, speed of iteration. Next.js plus Vercel plus Supabase is the closest thing the modern web has to a pre-fab kit for a real SaaS. Auth is solved. Email is solved. Hosting is solved. Database is solved. You can ship a new feature from idea to production in a working day if the design is clear. That mattered because every week between idea and first paying site was a week of opportunity cost.

Reason two, AI assistance fits this stack. Cursor and Claude Code both understand Next.js App Router idiomatically. The boilerplate is small, the conventions are tight, and the boundaries between server and client are well-defined. AI-assisted code review on a TypeScript Next.js project is significantly better than on, say, a custom Rails app with bespoke conventions. Every senior decision compounds when the boilerplate is delegated.

Reason three, the user does not care. A petrol station operator does not care if their POS is React or Vue or PHP. They care that the screen loads in under a second, that the clock-in works when the network is flaky, and that the data is recoverable if the till gets dropped in oil. The stack decision was made for the developer, not the user. That is fine, as long as the developer can ship faster because of it.

Honest opinion: if you are building an SMB SaaS in Australia in 2026 and you are not on Next.js plus Vercel plus Supabase plus Stripe, you should have a strong reason. The default is the default for a reason.

What we built in the first four sprints

Each sprint is two weeks of focused work. We shipped to staging at the end of each sprint, ran it against one real site, and refined based on what broke.

Sprint 1: Auth, sites, staff, roles

The first two weeks were the unglamorous foundation. Multi-tenant data model. Sites belong to organisations. Staff belong to sites with role assignments. Magic-link auth via Supabase. Staff PIN auth as a separate flow because forecourt staff cannot be asked to type a sixteen-character password while a customer is waiting.

We over-engineered the data model. The first version had a "tenancy" table separate from "organisation" because I had read too many SaaS architecture posts. The simpler model, where organisation is the tenant, would have shipped in three days instead of seven. The lesson, which every senior developer relearns every project, is that you do not need to plan for the scale you do not have. Refactor later.

Sprint 2: Rostering and the schedule view

The schedule view is the heart of ServoSimple and was the hardest visual problem to solve. Petrol station owners want to see two weeks of staff coverage at once, with hours-per-week running totals, overtime flags, and the ability to drag a shift from one staff member to another without losing the cursor.

We shipped three iterations of the schedule view in two weeks. The first was a CSS grid with absolute positioning. It broke at four staff members because the grid columns started overlapping shift cells. The second was a virtualised table using TanStack Table. It worked but felt sluggish on a touch device. The third, which is what shipped, is a custom flexbox layout with a Tailwind grid wrapper, no virtualisation, and pre-computed shift positions calculated on the server. It loads in 0.7 seconds on a five-year-old iPad mounted on a forecourt wall.

The bold opinion: most SaaS rostering tools fail because the schedule view is built by a developer who has never rostered staff. Watching a sixty-year-old petrol station owner try to use a drag-and-drop schedule was the most valuable user research I have done in any project.

Sprint 3: Timesheets, payroll exports, and the BAS-friendly date model

Timesheets are derived from rostered shifts plus actual clock-in clock-out events. Sounds simple. Becomes complicated when you account for shift swaps, unscheduled overtime, public holiday rates, junior-rate vs adult-rate transitions, and the way AU payroll runs on fortnightly cycles that do not align with calendar months for BAS reporting.

We built a custom date utilities layer that handles AU public holidays per state, fortnight-aligned payroll periods, and BAS quarter rollovers. We exported timesheets to Xero, MYOB, and CSV. The Xero integration alone took longer than the original spreadsheet replacement.

The fortnight-vs-calendar-month problem is one of those things that is not in any tutorial. You have to talk to an AU accountant to even know it exists. We shipped a half-broken first version that grouped hours by calendar week, which was wrong for sixty percent of payroll runs. Fixed it in week six.

Sprint 4: Drive-off logger and the integration story

Drive-offs, where a customer fills up and leaves without paying, are a daily reality at AU petrol stations. The current standard practice is a paper log in the office drawer that nobody updates. The data is gold for working out which pumps need a forecourt attendant during which hours, but nobody has the data because nobody logs it.

We shipped a drive-off logger in sprint four. Three taps on the iPad: pump number, estimated fuel value, time. Photo of the CCTV grab attached if available. Auto-flag if the same number plate appears twice in a month. By the end of sprint four, the pilot site had recovered eleven hundred dollars in unpaid fuel by matching plates to follow-up calls.

Sprint four also included the first version of the integration framework, which has since become the AI Fill feature. AI Fill uses the live shift data and the day's transactions to draft a daily handover note for the next shift in plain English. It is the kind of feature that took two days to build because the data was already there.

What we got wrong

Three things I would do differently.

The first sprint over-built the data model. Two extra days spent on tenancy abstractions that we have not used. Two days at senior rates is roughly fifteen hundred dollars. It would have been better to ship the org-as-tenant model and refactor when we had three customers asking for the same thing.

The schedule view took three iterations to land. Two of those iterations were not necessary. We could have skipped the CSS grid attempt entirely if we had spent thirty minutes sketching the layout on paper first. The senior version of me knows to sketch. The shipping version of me went straight to code. That added a week.

The Xero integration shipped too early. We built it because the first pilot site asked for it. The second pilot site does not use Xero. The third uses MYOB. The fourth uses Reckon. We should have shipped a CSV export first and added accounting integrations only when three or more customers asked for the same one. The Xero integration absorbed twelve days and has been used by exactly one customer so far.

These are not catastrophes. They are the regular mistakes a senior team makes when they are moving fast. The reason senior teams ship despite the mistakes is that they spot them within a sprint and correct, instead of building three more layers on top of the wrong foundation.

The numbers, real ones

Total elapsed time from idea to first paying customer: eleven weeks. Total senior developer hours: roughly four hundred and twenty. AI assistance cost: about two hundred dollars in API spend across the entire build. Hosting cost during development: under one hundred dollars per month combined across Vercel, Supabase, Stripe and Resend.

First paying site signed up in week twelve. Second site signed up in week fourteen. Third site in week sixteen.

The category leader charges nineteen ninety-nine per site per month for an objectively worse product. ServoSimple ships a better product at sixty-nine ninety-nine per site per month with a lifetime-deal option at five hundred ninety-seven. That pricing decision is the difference between a hobby project and a real business. Most SaaS builders price too low because they are scared of the conversation. The conversation, in our case, was about eight minutes long with the first paying customer.

What this means for your build

Three takeaways for any AU SMB owner thinking about a custom build right now.

One. The maths on custom software in 2026 has changed. AI assistance has not replaced senior developers. It has made senior developers two to three times more productive on the specific kind of work that fits AI assistance well. ServoSimple in 2019 would have cost eighty thousand dollars to build by an agency. In 2026, the senior solo build is twenty-five thousand dollars in direct labour plus two hundred in AI spend. The gap is real and it is not closing.

Two. The right wedge is a workflow nobody has good software for yet. ServoSimple did not invent rostering. It made rostering tolerable for the seventeen specific things an AU petrol station owner does in a week. The gap between "rostering software" and "rostering software for a petrol station forecourt" is where the real value lives.

Three. Solo plus AI works for the right team size. ServoSimple is one founder plus AI assistance plus, now, two more senior developers as we scale to multi-site customers. For the first twelve weeks, solo plus AI was the right team. We avoided the meeting tax, the handover tax, and the "let me check what you meant by that" tax. If you are commissioning a custom build right now, ask the builder whether they have shipped a real product solo with AI. The answer tells you more than any portfolio.

Where to go from here

If you have a workflow nobody has good software for yet, and you are thinking about a custom build, our Voltari Operator tier is the closest fit. Fixed price, fixed timeline, custom application functionality with AI integration built in. We have the case study scar tissue because we built ServoSimple ourselves.

You can see ServoSimple live at servosimple.com. The pricing page is the same pricing page our first three paying customers signed up on. We do not hide it behind a contact form for a reason.

If you want to talk about whether your workflow is a build candidate, send a brief to /contact. We will tell you honestly if SaaS is the right answer instead, which it sometimes is.

ServoSimple was twelve weeks. Your build might be six. It might be twenty. The maths is the conversation, not the brochure.