Engineering for your business

Custom software development

Web systems built around your operating rules. Custom software connects people, processes and data when off-the-shelf tools no longer support the work your business needs to do.

Problems I can address

  • Information scattered across spreadsheets and disconnected systems.
  • Workflows dependent on manual checks and one person's knowledge.

What the scope can include

  • Process map, business rules and acceptance criteria.
  • Web application with role-based access and workflows.
  • Database, integrations, tests and operating documentation.
  • Source code and infrastructure handover as agreed in the contract.

When to consider it

For businesses that need workflows with specific rules, access roles or an audit history.

Possible applications

Potential scope, not completed-project claims:

  • Internal portal for requests, ownership and approvals.
  • Order management with custom pricing and authorisation rules.
  • Document tracking with history and role-based access.

What affects the estimate

Effort depends on business rules, access roles, the volume and quality of data to migrate, and connected systems. A single approval flow differs from several departments with exceptions. Bring one real task, the people involved and the work currently done outside the system.

Limits and decisions

Owned software requires maintenance. Before building, I assess whether configuring an existing tool solves the problem at a lower cost.

The deliverables on this page guide the proposal. Integrations, migration, support, infrastructure and responsibilities are confirmed in the agreed scope.

An approval needs an explicit rule

Separate reading, creation, review and approval before development. Identify authorised transitions and an actual exception. I can design interfaces and validate the same rules on the server, including prohibited access and concurrent edits. Existing-tool configuration should be compared when it fits. Data, migration, recovery and maintenance need agreed scope; isolated screens are not a complete operation.

How the work progresses

  1. Observe an existing workflow and record rules, exceptions and ownership.
  2. Prototype the main journey and agree acceptance criteria.
  3. Build data, permissions and screens in verifiable increments.
  4. Validate migration, recovery and operational handover.

FAQ

Before we begin.

Do I have to replace my existing tools?

Not necessarily. Assessment may suggest a complementary module or an integration. Replacement needs a defined benefit and transition plan.

How are permissions defined?

We map who can view, create, approve and modify each record. Tests verify these rules on the server as well as in the interface.

Can spreadsheet data be reused?

Yes, with authorised access and sufficient structure. Duplicates, formats and matching rules need checking first; cleanup and migration form part of the scope.