§ 00Business systems
Comtau designs and builds the software your operation runs on: the records you manage, the people who handle them, the decisions they make and the systems they report to. The rules are yours, not a vendor’s defaults.
Audit trail
What a business system is made of
§ 01Operation
Most companies that need custom business software already have a process. It runs through forwarded emails, a shared spreadsheet with a “status” column, a chat thread and somebody who remembers what was agreed. Software makes that process explicit: every request becomes a record, every handoff becomes a state, and every approval has an owner and a timestamp.
| BeforeToday: inbox and spreadsheet | AfterIn the system |
|---|---|
| emailA site lead emails a purchase request with a PDF quote attached. | recordThe request is a record with required fields; the quote is attached to it, not to a thread. |
| spreadsheetSomeone copies the amount into a tracking sheet and colours the row yellow. | ruleThe budget code and amount are validated on submit. The routing rule picks the approver. |
| chatThe manager replies “ok” in chat. Finance never sees it. | decisionThe approver decides in their queue. The decision, the person and the time are logged. |
| re-keyingFinance types the order into accounting at the end of the week. | integrationThe approved request posts to accounting as a bill, once, with a reference back to the record. |
| asking around“Has anyone ordered the racking?” is answered by whoever is in the office. | doneThe requester, finance and the warehouse see the same state: ordered, with an expected date. |
§ 02Anatomy
Seven building blocks. Every system on this site is a different arrangement of them.
Custom business software development is the work of writing your operation down precisely enough for software to run it. Whether the project is called business management software development or operations software, these are the parts we define with you before any screen is designed.
The things your business manages: orders, purchase requests, jobs, work orders, stock movements, contracts, claims. Each record has an ID, required fields, attachments and links to related records. Getting this data model right is most of the work. Everything else depends on it.
The lifecycle of each record (draft, submitted, approved, in progress, closed) and the transitions that are allowed between them. States are what people mean when they ask “where is it?”.
Who can create, edit, approve, export or see sensitive fields such as cost prices or salaries. Roles come from your org chart and your approval policy, not from a generic admin/user split.
Validations, thresholds and routing: “orders over the credit limit go on hold”, “purchases above $5,000 need finance”, “a job cannot close without a signed checklist”. Rules are written down, tested and changed without rewriting screens.
What the system exchanges with the tools you keep: accounting, CRM, payment providers, carriers, email and chat, identity and single sign-on. Each connection has a direction, a payload and a trigger.
Operational views that answer daily questions: what is waiting for me, what is overdue, where work piles up, and what was done last month. They are built from the same records, so the numbers match the work.
Every change, approval and integration call is recorded with who, what and when. It answers disputes, supports audits and makes it safe to automate steps people used to check by hand.
§ 03States
This is the lifecycle of a field service job, a typical case of operations management software development. The diagram is the specification: each state has an owner, each arrow has a rule, and the one diamond is where a person must decide.
↺ Rejected · back to On site with a note; the SLA clock keeps running
§ 04Roles
Access control is a business decision before it is a technical one. We write the role matrix with the people who own the process, then enforce it in the system on every screen, export and API call.
| Role | Create | Edit | Approve | See cost prices | Export | Change rules |
|---|---|---|---|---|---|---|
| RequesterAny employee | Yes | Own only | No | No | No | No |
| Site leadPer location | Yes | Own only | Approves ≤ $5,000 | Yes | No | No |
| Finance | No | Yes | Approves > $5,000 | Yes | Yes | No |
| Operations director | No | No | Approves > $25,000 | Yes | Yes | Yes |
| AuditorRead-only | No | No | No | Yes | Yes | No |
§ 05Integrations
Custom business software rarely replaces accounting or CRM. It owns the workflow those tools do not cover and exchanges data with them. Every connection is specified like this: which system, which direction, what data and on which event. Each one is retried safely and logged.
| Connected system | Direction | What moves | When |
|---|---|---|---|
| Accounting | Your business system → Accounting | approved bills | on approval |
| CRM | CRM → Your business system | won deals → orders | webhook |
| Email & chat | Your business system → Email & chat | notifications | on state change |
| Bank / payments | Bank / payments → Your business system | payment status | daily file |
| Carrier API | Your business system ↔ Carrier API | shipments · tracking | on dispatch |
| Identity provider | Identity provider → Your business system | users · groups | SSO sign-in |
§ 06Reporting
An operational dashboard is a work surface, not a wall of charts. It opens on what is waiting for the viewer’s role, lists the exceptions and shows where work piles up. Because it reads the same records the work runs on, nobody reconciles the dashboard with reality.
Orders, jobs and requests, written as the work happens.
Thresholds and SLAs turn records into flags: overdue, over limit, waiting.
Each role sees its queue and its exceptions first.
A person approves, reassigns or escalates.
The decision moves the record and notifies the next owner.
↺ Every action is written back as a record change, so the next view is already up to date.
§ 07Orders
For many companies the order is the record everything else hangs on. A custom order management system captures orders from every channel, checks them against credit, stock and pricing rules, routes exceptions to a person and coordinates fulfilment.
When we take on custom order management system development, the scope usually includes order capture and validation, credit and pricing rules, allocation against stock, partial shipments, returns and the invoice handoff to accounting. Stock records themselves (locations, movements, counts) belong to an inventory management system. If orders, stock, purchasing and finance must share one set of records, the right scope is a custom ERP.
§ 08System map
Most engagements start with one of these. They share the same building blocks (records, states, roles, rules, integrations), so a system can grow from one kind into the next without starting again.
The screens staff work in all day: queues, record views, bulk actions and role-based dashboards.
Requests, approvals and handoffs moved between people and systems by rules instead of forwarded emails.
Finance, purchasing, stock and operations working from one shared set of records.
Every stock movement recorded where it happens, with locations, counts and reorder rules.
Work orders, routings, shop-floor reporting and quality holds on the same data as planning.
Replacing an old system or a web of spreadsheets without stopping the business.
§ 09Decision
Custom software development services are not always the answer. When a standard product fits your process, buy it. Customized software development pays off where the process is specific to how you compete, or where several tools have to behave as one.
| Question | Off-the-shelf product | Product + custom extension | Custom business system |
|---|---|---|---|
| Your process is standard for your industry | Best fit. Configure and adopt. | Only if one step is missing. | Hard to justify. |
| The process is how you win or differ | You adapt to the product’s workflow. | Works while the extension stays small. | Best fit. The process is modelled as you run it. |
| Work crosses several tools | Manual re-keying between products. | Point integrations per product. | One workflow that calls the tools you keep. |
| Cost over time | Per-seat licences grow with headcount. | Licences plus extension upkeep. | Build cost up front, then hosting and change budget; no per-seat fees. |
| Who controls changes | The vendor’s roadmap. | Shared: vendor platform, your extension. | You. Code and data model are yours. |
| Time to first use | Days to weeks. | Weeks. | One process first, then expand in phases. |
§ 10Scale
Custom enterprise software development services add requirements that small systems can skip. When you compare an enterprise software development company or an enterprise application development company, these seven are the questions worth asking. A custom enterprise software development company should plan for them from the first data model, not as a late hardening phase. We do.
Access follows your identity provider; joiners and leavers are handled where IT already manages them.
Development, staging and production, with release notes and a rollback path for every deployment.
Change history, approval logs and integration logs kept for the period your auditors require.
Backups, export of all records in open formats and documented restore procedures.
Bulk imports, long-running jobs and many users editing related records at once, designed and load-tested.
Permissions enforced on the server for every screen, export and API call; encryption in transit and at rest; secrets kept out of code; dependencies kept patched.
Business rules covered by automated tests built from real cases; integrations monitored, with failures raised as exceptions instead of silent gaps.
Custom software development for small business teams should be small too. We start with the one process that costs the most time, usually the one with a shared spreadsheet at its centre, and build only the records, roles and screens it needs. The data model leaves room for the next process, so growth does not mean a rewrite.
§ 11Method
This is what working with Comtau as a custom business software development company looks like. Each phase ends with something you can hold: a document you can review, or software you can use. Delivery is phased so that one process runs in production before the next is built.
Working sessions with the people who do the work and the people who approve it. We record records, states, owners, rules, exceptions and the tools involved.
The records, their fields and relationships, the role matrix and the integration list, reviewed with your process owner and your IT lead.
One complete process, built end to end on your real data with the people who will use it. Feedback changes the system, not a slide deck.
Connections to accounting, CRM and other tools; import of existing records from spreadsheets or the old system, with reconciliation reports.
Further processes added one at a time, each with training for its roles and a period of side-by-side running where needed.
You receive everything needed to run, change or move the system, whether or not we continue to support it.
§ 12Questions
Cost is driven by four things: the number of distinct records and states, the number of roles with different permissions, the number of integrations, and how much existing data has to be migrated. A single process with two integrations is a very different project from a multi-department system. After the process-mapping phase we give a phased estimate, so you can fund the first process before committing to the rest.
We put one complete process into production before building the next, so people use the system early and the remaining phases are planned from real feedback. The length of each phase depends on the scope we map with you; we state it per phase rather than as one large number.
SaaS describes how software is delivered: a vendor hosts one product for many customers. Enterprise software describes what it is for: systems that run a company’s core operations, with many roles, integrations and audit needs. A custom enterprise system can be hosted like SaaS in your cloud account, but it is built for one organisation and its rules. That distinction is worth asking about whenever a vendor offers enterprise app development services.
You do. Source code lives in your repository, infrastructure is defined as code in your cloud account, and every record can be exported in open formats. The handover includes runbooks and admin access, so another team could take over the system.
Usually, yes. Most business systems keep accounting and CRM and exchange data with them through their APIs or file exchange. We specify each connection (direction, data, trigger, error handling) during the data and access model phase, before building it.
Rules, thresholds and routing are kept separate from screens, so many changes are configuration rather than development. Larger changes, such as a new state or a new role, go through the same map-build-accept cycle as the original work, and the audit trail keeps the history of what was in force when.
Next step
A useful brief names the records, the people involved, the approvals and the tools the work touches today. The brief form walks you through it in about ten minutes.
brief.txt · what helps us most
