Skip to content

Custom software development

Build web applications and internal tools around the people doing the work: the decisions they make, the exceptions they handle, and the systems they already use.

Discuss a software project

An approval process people can actually see.

A request currently moves through an inbox, a spreadsheet, and several follow-up messages. A focused application can make the status and next owner visible in one place.

  1. Request

    Capture the information needed to start. Show what is missing before a request reaches the next person.

  2. Review

    Route by agreed rules. Give the reviewer the evidence and permission needed to approve, reject, or ask for changes.

  3. Record

    Save the approved outcome to the agreed system. A failed write stays visible instead of appearing complete.

  4. Follow through

    Show status, history, and the next action. Let an authorized operator recover a stalled request.

A sensible first release

One request type, one approval path, and a visible exception queue can be a better starting point than recreating the whole business at once.

Illustrative example. Not a client project or measured result.

Buy, configure, or build?

  • Buy a standard product

    Start here when the process is common and the product handles the important exceptions, access rules, and data export needs.

  • Extend what you have

    Choose configuration or a focused integration when the existing system is sound and the gap is narrow.

  • Build around the difference

    Custom software becomes useful when a distinctive workflow, user experience, or system boundary is central to how the business works.

Compare the whole operating life: implementation, subscriptions, data migration, maintenance, support, and the cost of changing direction. Code ownership, licensing, deployment access, and handover belong in the agreement.

What the work covers

  1. Workflow and interface design

    Prototype the key journey with actual users, including empty states, errors, permissions, and work that cannot proceed.

  2. Application development

    Build the agreed release around clear business rules and interfaces. Add AI only where it improves a specific part of the workflow.

  3. Testing and maintainability

    Test important user journeys, accessibility, recovery, and data handling. Document how another developer can operate and change the application.

Possible outputs

  • A defined application scope and user journeys
  • A working application within the agreed release boundary
  • Tests and implementation documentation
  • An agreed deployment and handover plan

Illustrative outputs. Availability, support and ownership terms belong in the written scope.

Questions to settle early
  • Who needs to use it, and for what decision?
  • What should a first release do particularly well?
  • Who will operate and maintain it after launch?

Go deeper

Questions

Can a new application work with our existing tools?

Often, and it is usually a design requirement. Interfaces, data access and security are reviewed before any integration is promised.

Who owns the code?

That is made explicit in the engagement agreement: code, licensing, access and ongoing responsibilities.

How do we avoid an oversized first release?

Choose one end-to-end job and agree what is deliberately outside it. A prototype tests the workflow before development; a release boundary keeps later ideas from silently becoming requirements.

What will you
lead next?

Discuss a software project