By KYN AI Advisory Team — AI implementation specialists, Singapore
Custom software development for a Singapore SME takes a 14-day review, then a build that ships in under 90 days. Scope sets the timeline more than effort does. A build with one bottleneck, one measurable outcome and one existing tool to connect to moves fast. A build that keeps adding requirements does not. This article explains each stage, what to settle before you ask for a quote, and who owns the result.
How long does custom software development take?
Plan on three stages.
| Stage | Duration | Output | |---|---|---| | Review | First 14 days | Inventory of your stack, interviews with your team, a written scope | | Build | Under 90 days in total | Working systems, shipped in pieces | | Run | Monthly, minimum twelve months | Changes, monitoring and fixes |
The 14 days are a review, not a delivery date. Anyone who promises finished custom software in two weeks has not looked at your systems. The review is what makes the 90-day ceiling credible, because the scope is written after the inventory, not before it.
Large scopes ship in stages. Each stage goes live on its own, so you use the first part while the second is built.
What should be in scope for the first release?
Narrowing scope before you ask for a quote is the part you control. Run this exercise on paper first.
- Name one bottleneck. The task that backs up every week and costs hours or deals.
- Name one measure it moves. Operating cost, enquiries answered, days to invoice, hours saved.
- Name the tools it must connect to. The CRM, inbox, accounting package or channel your team opens every day.
- Write down what you are deferring. Everything else goes on a later list. Most owners skip this step, and it is the step that stops a short build turning into a long one.
The exercise also settles most build-or-buy questions. If your bottleneck is generic, buy a tool; our guide to HubSpot alternatives covers that case. If the pain sits in the gap between tools you already own, a custom build fills the gap.
What happens in the review?
Two things: an inventory and interviews.
The inventory lists every platform, spreadsheet and inbox the team works in, who owns it, what it feeds and what feeds it. The interviews cover how work actually happens, which differs from how the org chart says it happens.
From these we write a proposed system: what each part does, which actions an agent takes on its own, and which wait for a person. You approve the scope before any build starts. The quote follows the review. There is no price list, because the price depends on the inventory.
Do you have to replace your existing CRM or tools?
Not usually. Most builds add a layer on top and connect to what you have: capture and sort in one place, draft in another, log back to the system of record. Replace a tool only when it is the reason staff work around it.
Two live examples, described by industry only:
- Insurance brokerage. Outreach with one checkable first line per email at about S$0.02 each, a reply desk that sorts each reply at about S$0.01, and a group benefits comparison turned into a client PDF at about S$0.03.
- Manufacturer. Eleven systems consolidated to three on one AWS account, 10,210 vendor quotes moved, a ledger of 3,309 reconciled rows with zero duplicates, and a 06:30 morning report to each department on WhatsApp at about S$0.05 per report.
Per-unit costs depend on the model used and the length of the text. They are measured from our own running systems, not a forecast for yours.
What does a written scope contain?
A scope is a short document both sides sign. The outline below is illustrative, for an invented Singapore wholesaler.
| Section | Example entry | |---|---| | Problem | Supplier quotes arrive by email and are retyped into a stock sheet; 9 hours a week | | Outcome | Quote rows created in the sheet within minutes, checked against the source email | | Tools to connect | Shared mailbox, stock spreadsheet, accounting package | | What the system does alone | Reads quote emails, extracts line items, drafts rows | | What waits for a person | Row approval, any price change over a set limit | | Out of scope for release 1 | Purchase order creation, supplier portal logins | | Acceptance test | 50 historical quote emails processed; a person grades each row | | Review points | End of week 3 and end of week 6 |
The "out of scope" row is the one that protects the timeline. Every item in it is a candidate for release 2, priced separately.
How do you test a custom build before you accept it?
Accept a system on evidence, not on a demo.
- Test on history. Run the system on real past data in a copy of the environment. A sandbox with tidy examples proves little.
- Grade a sample. A person from your team grades 50 to 100 outputs against what they would have done. Record the errors by type.
- Test the failure paths. Switch off a connection, send a malformed file, and submit a duplicate. The system should flag each case, not fail silently.
- Check permissions. Log in as each role and confirm what each can see and approve.
- Rehearse the rollback. Know how to return to the old process for a day if something goes wrong.
Only after these pass does the system run on live data, and then in a mode where a person approves outputs for the first weeks.
How do you handle changes while the build is running?
Changes are normal. They need a rule.
- Small change, same goal: absorbed in the current stage if it fits the timeline.
- New requirement: written down, sized, and placed in a later release unless it replaces something already in scope.
- Change that affects permissions or money: a named person on your side signs it off.
Keep one list of requests with a date, the person who raised it and a decision. At each review point, read the list aloud. Two requests that sound different often turn out to be one.
What should you compare when you receive several quotes?
| Question | Why it matters | |---|---| | Was the quote written after reviewing your stack? | A quote without a review is a guess | | Does it name the cloud account owner? | Decides whether you own the system | | What does the retainer cover and for how long? | Sets the real three-year cost | | What is out of scope? | Shows where the extra fees will appear | | How is acceptance tested? | A vague test means a vague handover | | What happens at exit? | Tells you whether the system survives a change of supplier |
Two quotes with the same headline price can differ widely on these six rows. Ask each supplier to answer in writing.
What edge cases cause overruns?
- Data that is not clean. Duplicate customers, free-text fields and missing identifiers add work before any logic can run. Ask for a data check inside the review.
- A tool without an interface. Some older software has no export or API. The options are a scheduled export, a screen-based workaround or replacing the tool, and each has a cost.
- A decision maker who joins late. A new stakeholder in week 8 reopens settled scope. Name the sign-off person at the start.
- Seasonal peaks. If your busiest month falls inside the build, plan the release around it so staff are not learning a new system under load.
- Approvals that nobody owns. If the design says "a manager approves", name the manager and the deputy.
Who owns the code?
You do, on full payment. The system runs in a cloud account in your company's name. Rights in the custom code and configuration pass to you when the build fee is paid. You can revoke KYN's role at any time and everything keeps running.
Check this in any contract, with any developer:
- whose name is on the cloud account;
- who holds the repository;
- whether the licence is perpetual or tied to a monthly fee;
- what you receive if the relationship ends.
A system that stops when you stop paying is a rental. For standard software that is normal. For custom work it is a risk.
What does the retainer cover?
The fee shape is a one-off build fee, then a monthly retainer with a minimum of twelve months. It covers changes from live team feedback, monitoring and fixes. It exists because systems need an owner after launch. Rules change, a supplier moves, an API is retired, a team member joins.
Compare quotes on the three-year cost, not the build fee alone. A low build fee with a high licence, or a free build with no support, usually costs more later. The custom software maintenance guide lists what to expect.
How is the system kept secure?
Security is part of the design, not an add-on.
- Named accounts through the cloud provider's identity service; no shared logins.
- Row-level security in the database, so a user sees only their own rows.
- One restricted account per user per session.
- Agents have their own restricted accounts.
- Every action is logged with the actor.
- Outbound messages, money, filings and deletions wait for a named person.
The security page sets these out in writing.
Where KYN fits
KYN builds custom technical systems for SMEs in Singapore, Hong Kong, Indonesia and Malaysia: cloud infrastructure in the client's own account, a front end designed around each team's workflow, and agents for sales, marketing, operations and finance. A finance software startup had its receipts, claims and GST product built to production in six weeks on Google Cloud. See pricing and case studies.
Frequently asked questions
How long does it take to build a custom business system?
The first 14 days are a review of your stack and team. A full build ships in under 90 days, with early pieces live sooner. Scope drives the timeline: one bottleneck and one connected tool ship faster than a long wish list.
Do I need to replace my CRM to get custom software?
No. Most builds connect to the CRM and tools you already use and add capture, drafting and logging on top. Replace a tool only when it is the reason staff work around it.
Who owns the code when a custom system is built?
You do, on full payment. The system runs in a cloud account in your company's name, rights in the custom code and configuration pass to you, and you can revoke the developer's access while everything keeps running.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
