Building Better Systems: Lessons from Launching Our Own SaaS Product

For years we built custom software for service businesses across Singapore — clinics, studios, education centres, logistics firms — and we kept noticing the same thing. Different industries, different owners, but largely the same five operational problems: booking, reminders, packages, staff access and reporting. Singapore's digital economy has grown to 18.6% of GDP, up from 14.9% in 2019 (IMDA, 2025), and that demand was arriving at our door one near-identical project at a time. So we stopped rebuilding the pattern and turned it into product. This is the story of how that became BooknGo and, later, Automiq — and what the move from projects to products actually taught us.

If you run on spreadsheets today and feel that pull toward something more, our note on the signs you've outgrown spreadsheets is the conversation that usually starts a project like the ones below.

Why did we build a product instead of rebuilding?

We built a product because rebuilding the same features for each client is expensive in a way that compounds. Software maintenance, not the initial build, dominates a system's lifetime cost, and poor software quality cost the US economy an estimated US$2.41 trillion in 2022 (CISQ / Synopsys, 2022). Maintaining five bespoke booking systems multiplies that pain five times over.

Each custom build had to be tested, patched, secured and supported on its own. A bug fixed for one clinic never reached the studio down the road, because they ran different code. The economics only point one way: consolidate the recurring pattern into a single multi-tenant codebase, fix it once, and let every customer benefit from the same improvement. That is the core argument for productising work you find yourself repeating.

[PERSONAL EXPERIENCE] The tipping point was concrete. We caught ourselves quoting a fourth appointment system that was, feature for feature, what we had already shipped three times. Build-versus-buy is not just a client question; it is one we had to answer for our own roadmap. Our guide on custom software vs SaaS vs no-code lays out the same trade-off we worked through internally.

What changes when you move from project to product thinking?

Everything about the unit of design changes. A project serves one client; a product serves hundreds of tenants who will never meet. That gap matters because requirements and scope are where software most often goes wrong: industry research consistently finds only around 31% of IT projects fully succeed, with small, tightly-scoped efforts faring far better (Standish CHAOS, 2020).

With one client, you can quietly hard-code an assumption and nobody notices. With a product, that same shortcut breaks the moment a tenant in a different industry, on a different schedule, with different staff roles, signs up. So product thinking forces discipline: multi-tenancy, role-based permissions, configurable scheduling rules, sane defaults, and onboarding a non-technical owner can finish alone. You get exactly one chance to pick the right abstraction, then you live with it for years.

[UNIQUE INSIGHT] Counter-intuitively, this made our custom work better too. Designing for hundreds of businesses taught us which assumptions are genuinely fragile, so even our bespoke projects now start from cleaner, more honest foundations. The product discipline paid back into the consultancy. If you are scoping anything yourself, our piece on how to scope a software project distils the questions that save the most rework.

Which architecture decisions actually mattered?

Four decisions shaped everything that followed, and the ones that paid off were the ones tied to how Singapore businesses actually operate. With 95.1% of Singapore SMEs having adopted at least one digital area but an average depth of only 2.3 of six areas (IMDA, 2025), the opportunity was clear: meet owners on the rails they already trust, and remove friction.

The four principles we held to:

1. Multi-tenant, multi-location by default. Each tenant's data is isolated, with its own branding, services and locations. One codebase, many businesses, no leakage between them.
2. Modular, plugin architecture. Memberships, intake forms, staff schedules and payment methods run as independent modules. A small clinic switches on only what it needs; a chain switches on more.
3. Built for the local rails. PayNow QR and multiple gateways sit inside the booking flow, and Singpass SSO is available for enterprise sign-in — the identity and payment methods Singaporeans already use daily.
4. Security and PDPA by design. Consent and purpose tracking, encryption in transit and at rest, role-based access and audit trails are part of the data layer, not bolt-ons. This same layer became the foundation Automiq's KYC and customer-data handling runs on.

Wiring PayNow into the moment of booking was not a vanity feature. Around 92% of people in Singapore used a digital payment method in the year to November 2025 (PwC & the Singapore FinTech Association, 2026), with FAST handling hundreds of millions of instant transfers a year (MAS). Asking customers to pay the way they already pay simply removes a reason to abandon the booking. For the data side, our notes on handling customer data securely and Singpass and Myinfo integration cover the patterns we standardised on.

How did real users beat our internal testing?

Real users found problems our internal testing never could, because they are not us. Singapore SMEs have adopted digital tools almost universally yet shallowly — averaging just 2.3 of six digital areas (IMDA, 2025) — so the people using BooknGo are often busy owners and front-desk staff, not power users. What feels obvious to an engineer is rarely obvious to them.

[PERSONAL EXPERIENCE] We learned more from watching a receptionist take a walk-in booking during a lunch rush than from any internal QA pass. The screens we thought were clean were not; the labels we thought were clear were not. So feedback became a loop, not an event: short cycles of observe, refine the interface, ship, observe again. Many of our most useful changes were small wording and layout fixes that only surfaced once a real human, under real pressure, tried to get through a real task.

That is also why we treat support as a core feature, not a cost centre. Onboarding, documentation and a quick human reply are part of the product. For owners coming from spreadsheets and manual chasing, the hidden cost of manual work is usually what they are trying to escape — and good support is what gets them across the line.

Why did one product become two?

One product became two because booking is rarely the whole job. Sector-specific tool adoption among Singapore SMEs jumped to 97% in 2024, up from 85% the year before (IMDA, 2025), and our customers kept asking for more than scheduling. They wanted the enquiries, follow-ups and routing around the booking handled too.

[UNIQUE INSIGHT] BooknGo proved we could run sensitive customer data well; Automiq is what we built on top of that proof. The same PDPA-compliant data and KYC layer that secured bookings turned out to be the right foundation for AI enquiry handling, smart routing and workflow orchestration. The realisation was that we were not adding a feature to a booking tool — we were standing up a second platform. Automiq automates the work around operations, while every workflow still runs on data a business can stand behind. The thread from automated reminders to fuller automation is the same one we explore in WhatsApp automation for SMEs and what you can actually automate.

What lessons generalise for any SME going digital?

The lessons that transfer are not about our products; they are about how digital adoption sticks. Adoption in Singapore is near-universal but shallow, with SMEs averaging 2.3 of six digital areas (IMDA, 2025). Depth, not the first download, is where the value is. These principles are what moved our customers from "adopted something" to "actually running on it".

• Start simple, then iterate. Ship the few features that solve the core pain, learn from real use, and add depth deliberately. A tool nobody finishes setting up helps nobody.
• Treat support as a feature. Onboarding and a fast human answer decide whether a tool is adopted or abandoned in the first weeks.
• Design for the rails people already trust. PayNow at checkout and Singpass at sign-in remove friction because they are familiar, not novel.
• Remember a product is never finished. Roadmaps, not handovers. The system you launch should keep improving long after go-live.

How those lessons apply depends on whether you are buying a product or commissioning a build. The short version:

General guidance based on our own delivery experience, not a guarantee for any specific business; the right choice depends on your workflows, budget and timeline.

When should you build custom instead?

Most service businesses should buy a configurable product, and you shouldn't build what you can buy. Yet a real minority of operations don't fit any product, and forcing them to is how good money gets wasted — consistent with the project-failure rates research keeps reporting (Standish CHAOS, 2020). Custom wins in a few clear cases.

• Unusual multi-branch workflows that no product's configuration can capture.
• Deep integration across several existing systems that must work as one.
• Industry-specific rules a generic tool ignores, where the process is your edge.

That is the work our consultancy still does, alongside the products. We can configure BooknGo or Automiq for you, extend either to fit, or design something bespoke from scratch — see our software development services and how we work for the full picture. If you are weighing the decision, our guide on custom vs off-the-shelf walks through where each one wins.

About AppTech System — AppTech System is a Singapore custom-software team and the people behind the Automiq and BooknGo platforms, building web, mobile, AI and enterprise software for businesses in regulated industries. Talk to us.