Insights
Notes on digital transformation for Singapore business
Practical writing for people deciding what to build and how to build it. No predictions about the future of technology, no vendor cheerleading. Just the questions that come up in real projects and how we think about them.
What you will find here
These notes cover the decisions that come up before and during a build: whether to buy or build, what has to be true before AI features are useful, why integration work stalls, how to keep environments consistent, how to choose a CRM, and when a system deserves replacing rather than patching. Written for teams in Singapore running websites, mobile apps, and back-office systems side by side.
Each piece is short on purpose. Read the one that matches your current problem, then talk to us if you want the version specific to your setup.
-
Buy or build
When a subscription tool beats custom software, and when it does not.
-
Data first
What has to be in place before AI features do anything useful.
-
Integration
Why connected systems break, and the habits that keep them running.
-
Delivery
Environments, releases, and the bugs that only appear on one machine.
-
Platforms
Choosing a CRM that your website and app can actually feed.
-
Legacy
Repair or rebuild, and how to tell which one your system is asking for.
Most digital transformation projects do not fail on technology. They fail on data that nobody agreed on.
Choosing between custom software and off-the-shelf tools
The default should be to buy, not build. A subscription tool costs a fraction of a custom build and someone else maintains it. The exception is when your process is the thing customers pay you for, or when the manual workarounds between tools cost more than the software would.
A useful exercise is counting the manual steps between a customer enquiry and a completed order. If the number is high and involves copying data between systems, you likely have an integration problem, and that is often cheaper to fix than replacing everything.
Buy when
The process is standard across your industry and a subscription covers it without configuration work.
Build when
The workflow itself is what customers pay you for, or staff spend hours moving data between tools by hand.
Check first
Count the manual steps from enquiry to completed order. A high count usually points at integration, not missing software.
What AI adoption actually requires
AI features depend on data, and most businesses have data spread across a website, a CRM, and a back office with no shared definition of a customer. Before any model gets involved, the records need to agree.
Recent IMDA reporting on Singapore's 2026 digital economy found digitalisation near universal among local enterprises with AI use accelerating. That is encouraging, and it also means the competitive difference now sits in data quality and workflow design rather than in having any AI at all.
- One customer record that the website, CRM, and back office all agree on.
- Clean event data from your website and mobile app, because behaviour is what most automation runs on.
- Automation for routine handoffs, so AI features sit on a foundation that does not need constant repair.
Why integration projects stall
Integration work fails for boring reasons. An undocumented API changes without notice. Two systems use different identifiers for the same customer. Nobody agreed who owns the master record.
The fix is procedural as much as technical: document the endpoints, write tests that run against them, and decide the system of record before writing any code. Postman tests catch the breakages; the ownership decision prevents the arguments.
Containers, environments, and the cost of "it works on my machine"
Deployment problems often trace back to environments that drifted apart. A library version differs, a configuration file was edited by hand, and suddenly staging and production behave differently.
Docker containers standardise the environment so the same image runs everywhere. It is not glamorous, and it removes a category of bug that otherwise eats release days.
Where this shows up in practice:
- A release that passed every test on a laptop, then failed on the server because one package version differed.
- A settings file that someone edited directly in production, and no one wrote down what changed.
- Two environments that were set up months apart and slowly stopped matching each other.
A consistent container image turns those three into one repeatable deployment you can rerun without guessing.
CRM choices: enterprise depth versus team simplicity
Salesforce and HubSpot both work, and they suit different organisations. Salesforce handles deep configuration, complex sales processes, and larger service teams. HubSpot suits smaller teams that want CRM, email, and pipeline in one place without a configuration project.
Salesforce
Deep configuration, complex multi-stage sales processes, and larger service teams that need custom objects and detailed permissions.
- Fits when sales stages and approvals differ across teams.
- Expect a configuration project before it matches how you sell.
- Needs someone responsible for keeping fields and rules tidy.
HubSpot
CRM, email, and pipeline in one place for smaller teams that want to start working without a build phase.
- Fits when one team owns sales and marketing together.
- Useful defaults you can adjust without a developer.
- Watch the plan tier as your contact list grows.
The more important question is how the CRM connects to your website forms, mobile app, and back office. A perfect CRM that nobody's data reaches is worse than a simple one that everything feeds into.
What an AI-ready stack looks like
It starts with a single customer record that systems agree on, which means integration before intelligence. Then clean event data from your website and app, because behaviour data is what most useful automation runs on. Building in that order costs less than the reverse.
1
Integration
One customer record that the website, CRM, and back office all read and write to.
2
Event data
Clean behaviour data from the website and mobile app, captured in a shape your tools can use.
3
Automation, then AI
Routine handoffs run themselves, and AI features sit on a foundation that does not need constant repair.
When to rebuild and when to repair
Legacy systems earn a rebuild when the cost of change exceeds the cost of replacement, when the original developers are unreachable, or when security patches are no longer available. Otherwise, targeted repairs usually win.
We start these assessments with a code and infrastructure review, then give an honest split between what to keep and what to replace. Sometimes the answer surprises the client in a good way.
- Rebuild when
- Change costs more than replacement, or the original developers are gone.
- Repair when
- The core logic still works and the pain sits in a few known places.
- Review first
- A code and infrastructure review before any decision is committed to.
How we work on these questions
Every note above maps to work we do for businesses in Singapore: websites, mobile apps, and the digital products that connect them to the rest of the business.
Website development
Sites built around how your enquiry flow actually works, with the forms and integrations that follow it.
See our servicesMobile app development
Apps that share data with your back office instead of creating a second place to keep records.
See our servicesDigital products for business
Internal tools, portals, and integrations that put one shared record behind the work your team already does.
See our approachQuestions we get asked most
Short answers to the questions that come up after reading these notes. If yours is not here, send it over and we will answer it directly.
Ask us a question
Should we build custom software or subscribe to an existing tool?
Start by buying. Custom work earns its cost when the process is what customers pay you for, or when staff spend hours moving data between tools by hand. If the pain is mostly data copying, an integration is usually cheaper than a replacement.
Can we add AI features to what we already run?
Often yes, but the order matters. The website, CRM, and back office need to agree on one customer record and produce clean event data first. Skipping that step usually means maintaining the AI layer on top of records that keep disagreeing.
How do you decide between Salesforce and HubSpot?
By the shape of your sales process and the size of your team. Salesforce suits deep configuration and complex stages. HubSpot suits smaller teams that want CRM, email, and pipeline working quickly. Either way, we look at how the CRM will receive data from your website and app.
Our releases keep breaking. Where do we start?
With environments. If staging and production have drifted apart, containerising the setup so one image runs in both places removes a whole class of release-day bugs. It is unglamorous work that pays back quickly.
Do you review existing systems before proposing work?
Yes. Rebuild assessments begin with a code and infrastructure review, then we set out what to keep and what to replace. Plenty of reviews end with targeted repairs rather than a new build.
Bring us the question you are stuck on
Tell us what you are trying to build, replace, or connect, and we will tell you which of these notes applies. We are at Paya Lebar Square, Monday to Friday, 9:00 AM to 6:00 PM.
Prefer email or phone? Reach us at [email protected] or 5859 7306 89. Our office is at 60 Paya Lebar Road, #06-28, Paya Lebar Square, Singapore 409051.