Work & case studies
How a job like this runs
Illustrative example — this shows how a job like this typically runs, not a specific client engagement. Figures are representative, not measured outcomes.
A solo app founder Consumer Habit & Routine Tracking App
Protect · Fix & Secure an AI-Built App
Turning a Weekend Lovable Build Into an App With a Real Deploy Pipeline
The founder had built a genuinely good habit-tracking app in Lovable over a few weekends, but it only existed as a preview link and a folder of code on a laptop. Getting it in front of real users meant proper cloud hosting, a way to ship it as a real iOS and Android app, and a pipeline so every update didn't mean a manual afternoon in Xcode. We built all three, and set it up so a push to the main branch is what ships the update — not the founder remembering the eleven steps to do it by hand.
~20 min
Time to ship an update
Down from a manual afternoon rebuilding and uploading by hand
24/7
Uptime
Running on real cloud infrastructure instead of a laptop
None
Keys left exposed
Every certificate and key rotated and moved out of git history
2 of 2
Platforms live
Approved and live on both the Apple App Store and Google Play
What a working prototype was still missing
What we foundThe 'live' app was a laptop: Closing the lid took the preview offline. There was no server actually running the app anywhere.
Every release was manual, twice: Shipping an update meant a full manual build and upload in both Xcode and Android Studio — no shortcuts, no automation.
Signing certificates and API keys sitting in the repo: Apple's signing certificate and a live API key were committed straight into the project's git history.
The problem: There was no cloud hosting, no separation between a version being tested and the one real users would see, and no way to ship a bug fix without repeating the full manual build-and-upload process on both platforms. The founder wanted to spend weekends improving the app, not re-learning App Store Connect every release.
How we built the pipeline
9 business daysDays 1–2
Real hosting, split into test and liveMoved the backend onto proper cloud hosting with separate staging and production environments, so changes could be tried safely before anyone saw them.
Days 3–5
Wrapping it as a real appPackaged the web app for iOS and Android, set up proper code signing with certificates stored securely instead of in the repository, and got it accepted into both app stores.
Days 6–8
A pipeline that ships on its ownBuilt an automated pipeline so pushing to the main branch builds, tests and submits the update to TestFlight and the Play Console without anyone touching Xcode.
Fixed price:$1,150 AUD (fixed price)
A solo founder in shared electric mobility Sustainable Micromobility (E-Bikes & E-Scooters)
Build · Build Your First Version
Building a Shared E-Mobility Platform Around a Pricing Model That Had to Hold Up
The founder had worked out a genuinely sound pricing model — base rate, per-minute, per-zone surcharges, member tiers, off-peak discounts — across 40-odd rules in a spreadsheet, plus a list of which council-permitted zones each vehicle could legally operate and park in. We turned that into a booking platform with a pricing engine that recalculates live as a rider moves, geofencing that enforces each council's rules automatically, and the ride and incident logging needed to prove compliance if a council or insurer ever asked.
40+
Pricing rules automated
Every rate, surcharge and discount recalculated live on each ride
3
Council zones at launch
Each with its own enforced no-go areas and speed caps
5 Weeks
Time to a working platform
From pricing spreadsheet to a bookable, paying platform
100%
Pricing accuracy
Tested against every rule combination before launch
What the first version had to get right
What we foundPricing lived in a spreadsheet no developer could read: 40-plus conditional rules across vehicle type, time of day, zone and membership tier, worked out by the founder but never written down as logic.
A different rulebook per council: Each council had its own no-go zones, speed caps and parking rules, and reserved the right to change them with little notice.
Compliance meant proof, not just following the rules: Councils and the insurer both wanted ride and incident data retained and retrievable, not just a promise that the rules were being followed.
The problem: Two agencies had quoted for 'an app', without seeming to register that the pricing and compliance logic was the actual product — the app around it was comparatively simple. Get the rules engine wrong and the business either loses money on every ride or loses its council permit.
How the five weeks ran
5 weeksWeek 1
Turning the spreadsheet into a rules engineRebuilt the 40-plus pricing rules as data the app reads and recalculates from, live, instead of logic buried in code — so a rule can change without touching a line of code.
Week 2
Geofencing each council's rulesBuilt zone maps for each council area with its own speed caps, no-go areas and approved parking bays, checked automatically against the vehicle's live location.
Weeks 3–4
Booking, unlocking and paymentBuilt the ride flow — unlock, live pricing as the ride runs, in-app payment on completion — plus the member tiers and discounts from the original pricing model.
Fixed price:$4,350 AUD (fixed price)
A commercial construction company Commercial Construction & Fit-out
Automate · Automate the Repetitive Work
Embedding AI Agents Into a Construction Company's Project Workflow
Project managers were re-entering the same information into their project management platform, Xero and email, one at a time, for every variation and RFI. We connected the systems they already used, then added a small set of agents that watch for the events that actually matter — a slipping program, an RFI sitting unanswered, a variation ready to bill — and draft the next step for a person to approve, instead of a person having to notice it first.
14 hrs/wk
Admin hours saved
Across the project management team, back on running sites
Days to hours
RFI turnaround
Unanswered requests now surface automatically instead of waiting to be noticed
4
Systems connected
Project platform, Xero, site email and the client-facing record, now in sync
Zero
Re-keyed data
A variation or RFI is now entered once, not up to four times
Where the hours were actually going
What we foundThe same job, retyped into four systems: A variation logged once had to be manually re-entered into the project system, Xero, an email to the client, and the site file.
RFIs sat in inboxes: Requests to consultants and engineers lived in personal email with no shared record of what was outstanding or how overdue it was.
Slipping programs surfaced late: A site falling behind schedule usually only became visible at the next site meeting, days after it started slipping.
The problem: Nothing was really broken — the systems all worked — but nobody had connected them, and a slipping program or an unanswered RFI only surfaced when someone happened to notice, usually later than it should have.
The nine-day build
9 business daysDays 1–2
Connecting the systemsWired the project management platform, Xero and the site email inbox together, so an approved variation only has to be entered once.
Days 3–5
Agents that watch, not just move dataBuilt agents that watch for a program starting to slip, an RFI going unanswered past its due date, or a variation ready to bill, and draft the next action — a chase-up email, a billing entry, a flag on the site dashboard.
Days 6–7
A person still signs off everythingEvery drafted action lands in a review queue for a project manager to approve, edit or dismiss — nothing goes out or gets billed without a person seeing it first.
Fixed price:$1,450 AUD (fixed price)
A facilities management company Commercial Facilities Management
Build · Build Your First Version
Giving a Facilities Management Company's Clients a Reason to Stop Calling
Staff already knew a job's status the moment it changed — it just never reached the client without a phone call or an email. We built a client-facing portal on top of their existing job management system, giving building managers a live view of job status, invoices and compliance certificates, plus a shared message thread tied to each job so a staff member being off sick didn't stall a client's request.
80+
Buildings onboarded
Across the full portfolio within the rollout
Down sharply
Status-check calls
Building managers now check the portal instead of calling
Minutes
Time to a visible update
Down from however long it took someone to answer the phone
None
Staff retraining needed
The internal system stayed exactly as staff already knew it
What the client-facing side was missing
What we foundClients called to ask what staff already knew: A job's status, an approved quote, an overdue invoice — all sitting in the internal system, none of it visible to the client without asking.
No shared record of a conversation: Instructions and notes on a job lived in individual staff inboxes, so a staff member being off sick could stall a client's request with no one else aware it existed.
The old system had no way for anything else to read it: Built years earlier with no safe way for other software to reach its data — the first job was making the data reachable at all, without touching the system staff relied on.
The problem: Replacing the internal system was off the table — staff already knew it, and re-training the whole team wasn't worth the risk. What was needed was a client-facing layer that read from the existing system without staff having to change how they worked, on a system that had never been built with anything else in mind.
How the four weeks ran
4 weeksWeek 1
A safe way to read the old systemBuilt a one-way sync that mirrors job, invoice and compliance data out of the legacy system on a short delay, without touching how staff use it day to day.
Week 2
The client portalBuilt a portal where a building manager logs in and sees live job status, invoice history and current compliance certificates for every site they manage.
Week 3
A shared thread per jobAdded a message thread tied to each job that both staff and the client can see, so a request or instruction survives a staff member being away.
Fixed price:$3,750 AUD (fixed price)
An early-stage SaaS startup B2B Field Service Scheduling Software
Decide · AI Plan & Roadmap
Turning 'We Should Do Something With AI' Into a Shipped Feature and a Team That Uses It
The board kept asking what the AI strategy was, a competitor had rushed out a chatbot nobody used, and staff were already pasting things into ChatGPT with no shared rules about what was safe to share. We spent three days finding the one product feature actually worth building, ruling out four AI ideas that would have been decoration, and setting the team up to use AI properly day to day.
6 Weeks
Feature shipped
Automatic re-scheduling suggestions live in the core product
20% → 90%
Daily AI tool use
Once there was one supported tool and clear rules, not five random ones
4 of 5
Ideas shelved before spending
Dropped before any development time went into them
3 Days
Time to a decision
From board pressure and no plan to a signed-off roadmap
What three days with the team turned up
What we foundCustomers weren't asking for chat: Calls with six existing customers turned up nobody wanting to 'talk' to the software — they wanted the twice-weekly manual slog of re-scheduling around no-shows and cancellations handled automatically.
One idea was worth building now: Automatic re-scheduling suggestions when a job falls through scored well above four other AI-flavoured ideas on customer value versus what it would cost to build.
Customer data was already leaving the building: Staff were pasting support tickets and, occasionally, customer job details into personal ChatGPT accounts, with no one having decided whether that was actually safe.
The problem: The founders didn't know whether to build an AI feature into the core product, which of several ideas would actually help customers versus just look like an AI feature, and had no shared approach for how the team should use AI tools day to day. Building the wrong thing, or letting customer data leak into a public tool, both felt like real risks — and nobody at the company had the time or the mandate to work it out.
How the three days ran
3 business daysDay 1
Talking to customers instead of guessingCalled six existing customers about where manual work actually hurt, and ranked what came up by how often it bit and how much time it cost.
Day 2
Scoring five ideas, building oneScored five possible AI product ideas against customer value and build effort. Automatic re-scheduling suggestions came out well ahead — the other four were shelved before a line of code was written.
Day 3
Rules for using AI, and someone to own itWrote a one-page policy on what can and can't be pasted into AI tools, picked one tool for the whole team to standardise on, ran a 90-minute hands-on session, and named one person as the ongoing owner of AI decisions.
Fixed price:$525 AUD (fixed price)