Skip to main content

Approach

Start with the workflow. Choose the smallest sound change.

The first decision is whether to keep the current tools, configure them, connect them, or build something new. A custom system is considered when the workflow and business case support it.

Keep, configure, connect, or build

  • Keep the current tools when they already support the work reliably.
  • Configure an existing platform when a practical setup can close the gap.
  • Connect systems when a small integration can remove repeated entry or handoffs.
  • Build a custom system when the workflow, access rules, integrations, and operating cost justify it.
Read the guide to choosing existing tools or custom software

The outputs are selected for the engagement; not every project needs every artifact.

01

Understand the workflow

Map the business problem, users, current tools, constraints, integrations, exceptions, and success criteria.

Typical outputs

  • Workflow map
  • User roles
  • System boundaries
  • Integration inventory and constraints

02

Define the system

Determine scope, architecture, core workflows, technical constraints, responsibilities, and a practical delivery plan.

Typical outputs

  • Scoped requirements
  • Data model
  • Architecture decisions
  • Delivery milestones

03

Build and validate

Deliver iteratively and review working software regularly so assumptions can be corrected while changes are still manageable.

Typical outputs

  • Working increments
  • Product demonstrations
  • Acceptance feedback
  • Issue and decision tracking

04

Release and hand over

Release the agreed scope, document how it runs, and assign operating responsibilities. Ongoing support is defined separately.

Typical outputs

  • Release steps
  • Operating documentation
  • Source and account access
  • Agreed support plan

Agree who operates each part

  • Source code, repository access, and third-party accounts
  • Hosting, deployment, and environment credentials
  • Monitoring, backups, and incident handling
  • Maintenance scope, response times, and support fees
Pricing & Support

What stays visible during the engagement

  • The business problem and success criteria
  • Scope boundaries and open decisions
  • Working software and feedback
  • Technical constraints and integrations
  • Launch, handover, and follow-up responsibilities

A clear first step

Define the right project before committing to a build.

Start with a 15-minute conversation about the process, the people involved, and where work gets stuck. If a deeper assessment is useful, we can scope a discovery engagement around the decisions you need to make.

  1. 01

    Map the workflow

    Identify users, current tools, handoffs, exceptions, and the result the business needs.

  2. 02

    Choose the right approach

    Compare improving existing tools, connecting systems, and building a focused application.

  3. 03

    Define a useful first release

    Agree priorities, integrations, acceptance criteria, and what can wait.

  4. 04

    Make an informed decision

    Review proposed scope, cost drivers, delivery stages, and ongoing responsibilities before authorizing development.

Discovery scope, fees, and timing are agreed separately. An initial conversation does not commit you to a development project.

Discuss your project

A good first step is a clear workflow conversation.

Explain what happens today and where the friction appears. The goal is to identify the right system decision before committing to a build.

Discuss your workflowExplore solutions