AI Systems Development
(yes - what some people call “vibe coding”, done properly)
Custom software, integrations and full SaaS platforms, built with AI doing the heavy lifting and experienced people steering it. We use the same tools everyone is talking about, but we wrap them in the engineering discipline, testing and project management you’d expect from a team that’s been building for Australia’s larger online brands for a long time.
Systems Integration
Legacy Migration
SaaS Builds
App Development
WhatsApp + AI
Payments
Multi-tenant platforms
What’s changed
Software that used to need a team of six and nine months can now be built by a small senior team in weeks.
That’s not hype - it’s what we’ve seen on our own projects over the last 12 months or so, and it’s changed what’s realistic for a mid-sized business (or a digital agency with a client who’s been told their idea is “too big”) to actually build. The catch is that the AI tools are very good at producing code that looks finished and isn’t, so the value isn’t really in the typing any more - it’s in knowing what to ask for, spotting what’s wrong, and making sure what goes live is tested, secure and maintainable.
Which is where we come in. We focus on:
Senior people directing the AI, with a clear spec and architecture before a line of code is written
Automated tests, independent code reviews and staging environments on every build - not just the big ones
Plain-English communication, honest estimates (as ranges, because that’s what they are) and code you own outright
1,686
commits in six months on one platform
4,496
automated tests on that same platform
120k+
legacy records migrated on one project
2 days
from empty repo to a working MVP
Figures from our own products, Anggota and GlowApp (2026), and a client booking platform migration.
Four types of work
What we build
Most AI projects that land on our desk fall into one of four buckets. In practice there’s a fair bit of overlap (a SaaS build almost always involves integration, and a migration usually ends with a new app of some sort), but it’s a useful way to think about where you’re starting from.
01
Systems Integration
Joining the systems you already have - ERPs, CRMs, booking engines, payment gateways, government data feeds - so data flows once, automatically, instead of being re-keyed.
02
Legacy Migration
Replacing the piecemeal mix of old software, spreadsheets and “the system only Dave understands” with one modern platform - without losing data or stopping the business.
03
SaaS Builds
Multi-tenant software products with subscriptions, payments, onboarding and admin consoles - for founders, and for businesses turning an internal tool into a product.
04
App Development
Web apps, mobile-first apps and installable apps (PWAs), plus the messaging layer people actually use - WhatsApp, Instagram and web chat.
01 / Systems Integration
Joining legacy systems together
Almost every business we talk to has the same problem in a slightly different shape: the website doesn’t talk to the booking system, the booking system doesn’t talk to the accounts package, and somebody spends a good chunk of every week copying data between them (and occasionally getting it wrong, which is when the real cost shows up).
Integration work used to be slow and expensive mostly because of the reading - working out an undocumented API, a 15-year-old database schema or a vendor’s “flexible” CSV export. AI is genuinely very good at that part, which means we can spend far more of the budget on the things that matter: error handling, retries, logging, and what happens at 2am when the other system is down.
Typical integration work includes:
Website to booking engine, ERP or CRM (two-way where it makes sense)
Scheduled data importers from government and industry data feeds
Payment gateways - Stripe, PayPal, Xendit, DOKU and QRIS
WhatsApp Cloud API, email providers and SMS
Google Workspace add-ons and document automation
Geo-targeted and personalised content driven by your own data
Australian passenger transport & tourism operator
Integration
Booking engine API
→
WordPress + cache
←
Tourism data feed
←
Geo database
A high-traffic tourism site (millions of requests a day) was showing departure times and service status through heavy page templates that rebuilt everything on every visit - and a live delay could take up to 24 hours to appear on the website. We built a custom importer that pulls the full timetable roughly 12 months ahead from the operator’s booking-engine API every day, checks live service status every 15 minutes, and lets the operations team override anything by hand (their overrides always win).
Everything is served from one cached endpoint to four lightweight widgets across the site, and we replaced a failing third-party location service with a local geo database so visitors see the right departure point first.
Status updates
Up to 24 hours → within 15 minutes
Home page
16-19 seconds of server time per cold load → about 2.3 seconds
Location lookup
~600 ms → under a millisecond
Also
Got a 10,000-listing tourism data feed importing reliably again
02 / Legacy Migration
Replacing piecemeal and ageing infrastructure
This is the one we get asked about most, and honestly it’s the one where we’d urge the most caution - not because the technology is hard, but because the old system is usually doing a dozen things nobody wrote down. The CRM that also sends the invoices. The Android app that only works on one tablet in the warehouse. The spreadsheet with the macro.
So we start by mapping what you actually have (AI is very handy here too - it’ll read old code and database structures far faster than a person, and it doesn’t get bored), then we replace things in stages, running old and new side by side until the numbers reconcile. Big-bang cutovers make great stories when they go wrong, and we’d rather not be in one.
Our approach usually looks like:
Discovery and mapping - every system, every data flow, every “oh and it also does this”
A single source of truth - one database designed for where the business is going
Repeatable, tested data migration - scripts we can run, check and re-run, not a one-off copy
Parallel running and reconciliation before anything is switched off
Staged cutover with a rollback plan for each step
Bali fastboat tour company
Migration
Ageing booking platform
→
New AI-built booking platform
→
Web
Agents
Check-in
My Booking app
A busy fastboat operator was running on an ageing third-party booking platform - fragile, clunky for customers and staff alike, slow to get changes out of, and with very little new coming down the pipe. We replaced it with a booking platform built around how the business actually runs, from the first click on the website to the moment a passenger steps on the boat.
Migrated
120,000+ historical records - customers, bookings, passengers, payments and transfers
Matched
100% of historical bookings mapped to trips in the new system
Rehearsed
Every import run first with customer contact details masked, so a test could never message a real customer
Sales
Online booking with hotel pickups priced by distance, agent bookings with bulk passenger upload, Xendit and PayPal
Operations
Passenger manifests, mobile check-in with QR boarding passes, capacity forecasting and daily regulatory manifest reporting
Customers
My Booking - self-service trips, boarding passes and change requests, with email and WhatsApp notifications
My Booking, the customer app (new mobile design rolling out).
03 / SaaS Builds
Software products, not just software
Building a SaaS product is a different thing to building a website or an internal tool. You need proper multi-tenancy (so one customer can never see another customer’s data - this one keeps us up at night, in a good way), subscriptions and billing, onboarding, emails that look like your brand, an admin console for your own team, and a way to ship improvements every week without breaking anything for the people already paying you.
We know this because we build and run our own. That means the advice you get from us is coming from people who have had to deal with failed payments, support requests at odd hours and the “can it also do...” feature requests themselves.
What’s typically in a SaaS build with us:
Multi-tenant architecture with tenant isolation tested on every change
Subscriptions, trials and invoicing (Stripe, PayPal, Xendit)
Self-serve signup and onboarding, including sign-in via WhatsApp
Custom domains with automatic SSL per customer
Multi-language from day one, with AI-assisted translation
Super-admin console, usage reporting and audit logs
Staging rebuilt from anonymised production data
Anggota
Anggota
Membership platform for clubs & associations
Members, renewals, events, donations, online courses, a shop and a public website for every organisation - in English, Bahasa Indonesia and Malay, with payments in IDR, AUD and MYR.
WhatsApp sign-in and notifications
Stripe, PayPal, Xendit, DOKU and QRIS
~130 admin screens that work on a phone
Live
Ruledox
Ruledox
Rules-based document automation
Organisations turn their proposals and contracts into “blueprints”; people answer a guided interview and Ruledox assembles the finished Google Doc or Word file, with conditional sections and calculated fields.
AI detects fields when a template is imported
Google Docs add-on
Plain-English calculations turned into rules
Beta
Fliket
Fliket
Help desk that lives inside your project tool
Customer emails turned into tickets and then into project to-dos, with replies threaded both ways - so a small team could run support inside the tool they already used, and customers never needed a login.
Gmail, Microsoft 365 and IMAP inboxes
Two-way email ↔ task threading
Self-serve setup wizard and tiered plans
Earlier build (2025)
04 / App Development
Web apps, mobile apps and the chat apps people already use
Here’s a question worth asking before you commission a native iOS and Android app: will your customers actually download it? For a lot of businesses (especially in Indonesia and across South East Asia) the honest answer is no - but they’ll happily talk to you on WhatsApp all day long.
So we tend to recommend starting with a fast, mobile-first web app that can be installed on a phone’s home screen, plus a smart messaging layer, and only going native when there’s a real reason to (offline use in the field, device hardware, or an app store presence that genuinely matters to your market). It’s usually a much cheaper way to find out what people really use.
Mobile-first web apps and installable PWAs
Native iOS and Android where it earns its keep
AI assistants on WhatsApp, Instagram and web chat
Booking, availability and payment flows
Admin tools designed to be used on a phone, not just a desktop
GlowApp
App + AI
Web chat
→
AI receptionist
→
Bookings
A booking app and AI receptionist for Indonesian beauty salons. Customers message the salon on WhatsApp, Instagram or the web chat and the AI answers from the salon’s real menu, checks live availability across staff, hours and existing bookings, makes the booking and sends a QRIS deposit request - then gets out of the way the moment a staff member takes over the chat.
Built
Working MVP on day two; 278 commits over about 11 weeks
AI
Anthropic Claude, with tool use for availability and booking
Stack
Laravel, React, Postgres, WhatsApp Cloud API
Payments
Salons connect their own Xendit or PayPal - the money never touches us
Anggota on a phone
Mobile web app
Club committees don’t sit at desks, so the whole Anggota admin - around 130 screens - was rebuilt to work properly on a phone, and members sign in with a one-time WhatsApp link rather than yet another password.
AI inside the product
Built with AI, and often running on it too
There’s a difference between using AI to build software and putting AI into the software. We do both, and we’re fairly conservative about the second one - AI that drafts and a human who approves is very often the right answer, and nobody wants a chatbot making up prices.
AI receptionists
Answering customer questions and taking bookings on WhatsApp, Instagram and web chat - grounded in your real catalogue, prices and availability, with a clean hand-off to staff.
Drafted replies, human approved
AI writes the reply to an incoming WhatsApp message, a person checks it and presses send. Faster responses without handing over the keys.
Translation
Content kept in sync across languages automatically, so a bilingual site doesn’t quietly become a monolingual one six months in.
Document intelligence
Reading an uploaded template or document and working out its structure, fields and sections, so setup takes minutes instead of an afternoon.
Training on your content
Assistants that learn from your documents, pasted text or a scan of your existing website - and only answer from what you’ve given them.
Internal assistants
Support tools for your own team (in Slack, say) that can answer “how do I...” questions from your documentation and data.
How we work
Vibe coding, with a safety net
1
Discovery
What the business needs, what exists today, and what “done” looks like. Written down, agreed, and kept short.
2
Architecture
Data model, integrations, security and hosting decided by a senior developer - not left to whatever the AI suggests first.
3
Build in short cycles
Small changes, each with tests, deployed to staging so you can click around and give feedback every few days.
4
Two reviews, every change
An automated code review plus an independent reviewer that only sees the change and hunts for how it breaks. Fixes are tested and re-reviewed.
5
Launch & handover
Staged go-live, monitoring, documentation and a change log. You own the code and the accounts - full stop.
The honest bit
Vibe coding gets a bad rap. Some of it is deserved.
Ask an AI tool to build you an app and it will, very confidently, in an afternoon - and it’ll probably demo beautifully. What it won’t tell you is that the login can be bypassed, the payments don’t handle a declined card, or that one customer can see another customer’s data if they change a number in the address bar. (We’ve caught every one of those in review, which is rather the point.)
We don’t think the answer is to avoid the tools - they’re simply too good to ignore now - but you do need people who know what to look for, and a process that assumes the AI is wrong until it’s proven otherwise.
What you can expect from us
Automated tests written alongside the code (thousands on our larger platforms)
Security reviews on anything touching logins, payments or customer data
Separate staging and production environments, with anonymised data in staging
A change log for every non-trivial change, so nothing is a mystery later
Your repository, your hosting accounts, your code
Is it actually different?
Traditional build vs AI systems development
Traditional custom build
AI systems development with Sansiro
Time to first working version
Usually months, often after a long specification phase
Often days to a few weeks - you’re clicking around a real thing early
Cost
Large team for a long time, priced accordingly
Small senior team over a shorter period - typically a fraction of an onshore quote (we’d say 25-33% as a rough guide, but it really does depend on the project)
Changing your mind
Expensive, and usually a change request
Much cheaper - rework that took weeks can take days
Quality & testing
Varies a lot by team
Tests and two reviews on every change, as standard
Who’s in charge
Developers
Senior people, with AI as a very fast pair of hands
The ranges above are from our own experience, not a guarantee - some projects (heavily regulated ones, or ones with a lot of unknowns in an old system) take longer whichever way you build them.
Before you call us
When we’d talk you out of it
It might seem odd on a page like this, but we’d much rather you spent your money well. A custom build isn’t always the right answer, and we’ll tell you if we think there’s a cheaper way.
×
An off-the-shelf tool already does 90% of it. Pay the subscription, live with the 10%, and spend the difference on marketing.
×
Nobody will own it after launch. All software needs someone to make decisions about it. If that person doesn’t exist, we’d sort that out first.
×
The process itself is broken. Automating a messy process just gives you a faster mess - sometimes a workshop is a better first step than a build.
×
You need it in two weeks for a launch that can’t move. AI makes things fast, not magic. We’ll be honest about what’s realistic.
FAQ
Questions we get asked
Is “vibe-coded” software safe to run a business on?
It can be, but only if someone qualified is checking it. The AI writes a lot of the code; experienced people decide the architecture, review every change, write and run the tests, and handle the security-sensitive parts (logins, payments, customer data) with extra care. Software built without that is a risk, and we’d be the first to say so.
Who owns the code?
You do. It lives in your repository, on hosting accounts in your name, and you’re free to take it to another developer at any time. We’ll leave documentation and a change log behind so they’re not starting from scratch.
We’re a digital agency - can you build this white-label for our client?
Yes, and that’s a big part of what we do. Same as our website work: you can front the client relationship and we build, or we can manage both. Our pricing reflects the engagement model.
Can you work with our existing systems and developers?
Usually, yes. A lot of our integration work involves plugging into systems that other people built and still look after. We’re happy to work alongside an in-house team, and to hand over cleanly if that’s the plan.
Which AI tools do you use, and does our data get sent to them?
We mostly build with Claude Code and Cursor, and use models from Anthropic and OpenAI inside products where AI features make sense. We don’t feed your production customer data into AI tools to build the software - development and staging use anonymised data - and any AI feature that handles customer data in the live product is something we’ll discuss and agree with you first.
How much does it cost?
It depends a lot on the scope (we know, everyone says that). Our hourly rate for ad hoc work is IDR 1.26 million per hour, which is around AUD $100, but we prefer to quote fixed prices for defined pieces of work. As a rough guide our quotes tend to come in at 25-33% of resourcing the same project onshore in a Western economy - happy to give you a range after a short conversation.
How long does a typical project take?
A focused integration might be a couple of weeks; a first version of a SaaS product is more like six to twelve weeks; a legacy replacement depends almost entirely on how many systems are involved and how much nobody wrote down. We’ll give you a range up front and keep you posted against it.