A Booking CRM helps service professionals manage bookings, payments, and client relationships from one platform. A photographer running a solo business has three separate tools open at any given moment: Calendly for bookings, a spreadsheet for client notes, and Linktree on their Instagram bio. When a client books through Calendly, the photographer manually adds them to the spreadsheet. When the shoot is done, they manually update the spreadsheet with payment status. When the client rebooks, they start again from the beginning. Three tools, three hours a week of manual data synchronisation, and three different places where something can fall through the cracks.
Amuthi was built as a Booking CRM to close that gap — not by connecting three tools, but by replacing them with one platform that treats every client interaction as a single unified event. This post explains the product decision and what it cost us in engineering complexity.
Why a Booking CRM Is More Than a Calendar Tool
For a service professional, a booking is simultaneously a calendar event, a client record, a payment transaction, and a portfolio piece. Splitting these across three tools means three systems that each capture part of the picture and none that capture the whole. The unified model starts from a different premise: every interaction between a professional and a client is a “touchpoint,” and every touchpoint lives in one place.
The central entity in Amuthi’s data model is the touchpoint. A booking creates a touchpoint record. That record links to the client (automatically creating or updating their CRM entry), the payment (connecting to Stripe), and the professional’s portfolio. The client books once. The professional sees everything in one view, with no manual entry.
Technical Architecture of the Booking CRM
React frontend, Node.js backend, PostgreSQL database. Stripe Connect for payments — direct charges, meaning Amuthi never holds client funds, which avoids FCA Electronic Money Institution licensing requirements in the UK (more on this in Blog 9). Shipped in 12 weeks with a four-person team. We followed the same structured MVP development process that guides our startup product builds.
The data model decision that mattered most was centralising on the touchpoint entity. The alternative — building booking, CRM, and links as three separate modules with their own data models and a sync layer between them — would have been faster to build initially. We estimated 25 to 30 percent less engineering time to ship three separate modules. We chose the unified model because the sync layer would have become the most fragile part of the system and the most expensive to maintain over time. The extra engineering complexity upfront eliminated the data consistency problems that would have appeared in production.
What the unified model delivered
Zero manual sync. A client who books, pays, and messages all in one flow creates one touchpoint record that populates the booking calendar, the CRM card, and the payment ledger simultaneously. Sub-60-second booking from an Instagram bio — the entire flow from tapping a link to receiving an SMS confirmation takes under a minute on a mobile device. One view for the professional: a single dashboard showing today’s bookings, outstanding payments, and client history without switching tools.
What it cost
Roughly 25 to 30 percent more engineering time than building three separate tools would have required. The additional complexity was almost entirely in the data model design and the Stripe Connect integration. The payoff is a product that does not need a sync layer, does not have data consistency bugs, and does not require the professional to learn how three tools interact.
The Amuthi build is the clearest example we have of the custom software development approach to product architecture: invest in the data model, keep the complexity there rather than in the UX layer, and build something that the user never has to think about.
This is the first in a four-part series on Amuthi. Blog 9 covers the payments architecture. Blog 15 covers the booking flow UX decisions. Blog 16 covers the modular monolith approach.
FAQ
Is Amuthi available to use? Yes — see the Amuthi product page for current availability and pricing.
Can SynthWeb build a similar unified platform for a different service vertical? Yes. The touchpoint model generalises to any service professional with recurring client relationships. The MVP Sprint at /mvp-sprint is the typical starting point.
How long would a similar platform take to build? At the Amuthi scope and quality level, 10 to 14 weeks with a 4-person team. See /mvp-sprint for the process.
