Start with the workflow, not a feature list
Custom software is what a business commissions when a defined process needs software shaped to it: its roles, its records, its exceptions, its links to systems that already exist. The portal or approval queue that results is a capability inside it, not the thing you are buying. A conversation that opens with a list of screens ends in a quotation for the wrong system.
Before speaking to anyone, see whether you can answer five things about the process. What it is called. Who touches it, and in what order. Where the authoritative record lives today. Which exceptions keep recurring. What should be different afterwards. If they do not come easily, establishing them is the first piece of work.
Fit is something to investigate rather than a verdict. Plenty of enquiries here are better served by a website, a store or an app, and our services route those to the right page.
Who the Malaysian economy actually is
Published statistic. Nearly half the country works in a small business. Software priced and shaped for a multinational is not software for this market.
Source: Department of Statistics Malaysia: MSME Performance 2025. Reviewed .
Also: DOSM: Economic Census 2023, profile of MSMEs.
Read the graphic as text
- Of national GDP: 39.7%. RM689.8 billion of value added by micro, small and medium enterprises in 2025, growing faster than the economy as a whole
- Of all employment: 48.7%. 8.09 million people work in one
- Establishments: 1.07m. Counted in the 2023 Economic Census, three quarters of them micro-sized
When an existing product genuinely wins
Assess the alternatives properly and the argument usually settles itself. For each candidate, record how much of your core process it covers, where its configuration stops, what must be integrated around it, and which gaps remain. Written down, they are usually smaller than the sceptics believe and larger than the vendor implies.
A product tends to win when your process resembles how most businesses in your sector run it, when the gaps are cosmetic, when nobody internally will own a bespoke system, or when the budget covers building something but not running it. We would rather say that during scoping than after a build. A build earns its place where the process is part of how you compete, where systems must stay in step continuously, where access must be controlled precisely, or where rules change faster than somebody else's road map.
The platform decides more than the theme
Published statistic. WordPress can be fast, and ours are. But the average WordPress site is not, so the plugins, hosting and theme decisions are the project, not the paint.
Source: HTTP Archive: Web Almanac 2025, CMS. Reviewed .
Read the graphic as text
- Duda: 85%.
- TYPO3: 79%.
- Wix: 74%. Up from 55%
- Weebly: 47%.
- WordPress: 45%. The largest group
Chart scale: Share of mobile sites on each platform passing Core Web Vitals, July 2025.
Configure, integrate or build
The table below is how we run that decision: a conversation with a shape rather than a scoring tool. There is no automatic verdict, and ending inconclusive on one factor tells you what to investigate next.
| Factor | What to ask | Evidence to collect | Favours configuring | Favours building |
|---|---|---|---|---|
| Workflow uniqueness | Does your sector generally run this the same way? | A written walkthrough of the process today | Differences are preference, not advantage | The process is part of how you compete |
| Integration depth | Which systems must stay in step, and in which direction? | Each system, its record owner, its interface | Few connections, one way, published interfaces | Systems must agree continuously, or no interface exists |
| Operational risk | What happens on a day it is wrong or unavailable? | The manual fallback, and which records are sensitive | A short outage is survivable | Access must be per role, errors carry consequences |
| Rate of change | How often do the rules behind it change? | The last three changes and what each cost | Changes are rare, or already exposed as settings | Rules move faster than a vendor road map |
| Ownership readiness | Who will run, fund and decide this after launch? | A named owner and a budget line | No internal owner, no care arrangement | An owner, a budget, appetite to improve it |
A distinctive workflow can still favour a product when the gaps prove small, and an ordinary one can still justify a build when integration and ownership point that way.
Three routes, and the condition each one needs
Editorial framework. There is no automatic verdict, and a factor that ends inconclusive tells you what to investigate next.
Basis: Perfect Design: business systems explained. Reviewed .
Read the graphic as text
- Configure. The process is ordinary, so bend to the product
- Integrate. Good products exist, the gap sits between them
- Build. The workflow is part of how you compete
What owning software actually costs
The build price is what everyone compares. The running cost decides whether the system still works in three years. Software nobody owns degrades quietly: dependencies age out of support, an interface changes, and the people who understood the rules move on.
So care is quoted with the project rather than bolted on afterwards. For a system with a real backend it starts from RM 250 a month, confirmed against what was actually launched, and covers hosting, security updates and upkeep. Support requests are normally answered in under one working day, which is how we work rather than a contractual guarantee; responding is not resolving, and a formal commitment can be written into your scope.
The e-Invoice mandate is already fully live
Published statistic. Every phase has passed. If a system issues invoices, e-Invoice is not an upcoming project, it is a current obligation with a turnover threshold attached.
Source: Inland Revenue Board of Malaysia: e-Invoice implementation timeline. Reviewed .
Read the graphic as text
- Above RM100 million. Mandatory since 1 August 2024
- RM25 million to RM100 million. Mandatory since 1 January 2025
- RM5 million to RM25 million. Mandatory since 1 July 2025
- Up to RM5 million. Mandatory since 1 January 2026
- Under RM3 million. Exempt, unless the company belongs to a larger group
Most failed projects failed at scoping, not at coding
When a software project goes wrong, the post-mortem rarely finds bad code. It finds an exception nobody mentioned, two departments that each believed they owned the same record, or an integration assumed to exist. Those failures are cheap to prevent and expensive to find late, so discovery comes before an estimate here.
The table below is illustrative rather than a client project: a wholesaler takes orders by email and checks stock in a spreadsheet, while a packaged system owns the customer record and another owns availability. The columns matter more than the answers.
| Workflow step | Assumed actor | Proposed system response | Exception | Acceptance evidence to collect |
|---|---|---|---|---|
| Receive an emailed order | Sales coordinator | Create a draft order and validate customer and item identifiers against the agreed sources | An identifier is missing or does not match | Run valid and invalid fixtures, keep the validation messages |
| Check and reserve availability | Stock controller | Ask the inventory system for availability and record the reservation | Stock is short, or the response is stale | Test available, unavailable and timeout cases, then reconcile |
| Approve an exception | Operations manager | Route it with its reason, proposed action and decision history | The approver is unavailable or lacks the permission | Test permitted and denied decisions, escalation and audit history |
| Confirm fulfilment | Fulfilment coordinator | Mark the order ready and send the agreed status onward | The integration is down, or the message arrives twice | Test retry, duplicate handling and reconciliation |
Every row names an exception and a test to run, not a result already achieved. Until the owner of the customer record and of the availability figure are agreed, no synchronisation rule or migration plan can be designed. CRM and system integrations covers that ground.
Architecture and security, at the level a buyer needs
You do not need to choose a technology. You do need to recognise the boundaries, because cost and risk live there: the interface people use, the rules that decide what may happen, the authoritative records, the edges where other systems connect, and the operating environment.
- Identity and permission are different questions. Proving who somebody is does not decide what they may do.
- Give each role only the access the work needs. Start closed and open deliberately.
- Decide which records are sensitive, and what may appear in an export or a log.
- Agree what gets recorded when something significant happens, so a disputed action can be reconstructed.
- Test a restore, not just a backup. A backup nobody has restored is a hope.
Delivery form follows the workflow. Work that lives on desks, counters and tablets usually belongs in a browser: see web application development. Work that depends on the phone in someone's hand is a case for mobile app development. We build in React by preference and work in other languages when a project calls for it.
Where the individual systems are covered
Business systems are assembled from recurring parts. Rather than describe each here, this page routes to the one that owns it.
- Accounts and portals for logins, roles and what each role may see.
- Admin dashboards for the screens your team works in daily.
- CRM and integrations for keeping customer and operational records in step.
- Catalogue and search when people must find one record among thousands.
- Booking and scheduling for availability, capacity and appointments.
Prove the smallest safe rollout
A first release is bounded by users, one slice of workflow, the records it touches and the risk it carries, not by counting features. Pick the slice where being wrong is recoverable, run it beside the current process, and use the acceptance evidence column as the checklist: permitted actions, refused actions, exceptions and an interrupted integration.
Where legacy data moves, add migration checks: record counts on both sides, relationships that survived, rejected records with reasons, and a business owner who signs off. Then make the widening decision explicitly, recording open defects, deferred scope, ownership and the condition for rolling back. With those written down it is a decision; without them it is a hope with a date on it.
What bounds a first release
Editorial framework. A first release is bounded by risk you can recover from, never by a count of features.
Basis: Perfect Design: business systems explained. Reviewed .
Read the graphic as text
First release
- Users. One team who will say when it is wrong
- Workflow slice. One path, run beside the current process
- Records touched. Real data, counts checked on both sides
- The way back. A written condition for stopping and reverting
Ownership, and who decides what
You own everything we build: the source code in your own repository, the domain and DNS registered to your business, the service accounts in your name, and the data in the system. There is no lock-in, and if you move provider we help with the handover.
A proposal should also be explicit about authority and upkeep, and it is worth checking any proposal against this list. Who controls the accounts. Who may approve a change. Who accepts a release. Who handles upkeep, defect correction, monitoring and security updates. Where new feature work stops being upkeep and becomes its own job.
What to bring to a first conversation
One workflow, the people it affects, the tools in use today, one representative exception, and your real constraints on budget and timing. That is enough to discuss what needs investigating before scope is agreed, and you are welcome to get in touch with exactly that much.
