Our approach

Good software starts
with clarity.

Understand the problem. Build with intent. Verify the result.

How we work

One shared direction.
Four practical stages.

The process scales to the project. A small utility should not carry the overhead of a large platform, but both deserve a clear definition of done.

  1. Discover

    Define the problem before choosing the technology.

    We discuss your users, current workflow, constraints, and what a useful result looks like.

    What you get

    A shared brief and a practical starting point.

  2. Design

    Turn the brief into a clear plan.

    We agree on the scope, technical direction, milestones, and acceptance criteria before the build expands.

    What you get

    A scoped proposal with explicit deliverables.

  3. Build

    Make progress you can see and test.

    Working increments make it possible to review the experience early and adjust with evidence, not guesswork.

    What you get

    Reviewable software and regular checkpoints.

  4. Refine & deliver

    Prepare the software for real use.

    Testing, deployment planning, documentation, and handover are part of the delivery conversation, not an afterthought.

    What you get

    Handover materials, verification results, known limitations, and agreed next steps.

Scope follows the problem

What needs to work better?

If customers cannot find information or complete a task, start with website and business application development. We define the user journey and the content or records behind it.

If your team repeats the same copying, checking, or reporting, explore workflow automation and data tools. We identify which steps can be repeatable and where a person must stay in control.

If you need to explore how a system behaves, consider interactive simulation and visualization. We agree on the scenario, assumptions, and evidence needed to judge the result.

Before we begin

A few useful answers.

Do I need a complete specification?

No. Start with the problem, who it affects, and what you want to improve. A scope discussion identifies the next questions. Any separate discovery work is agreed before it begins.

Can you improve an existing website or tool?

Yes, subject to a technical review. The starting point is its code, dependencies, documentation, and access requirements. That review helps establish whether to improve the current system or consider a different approach.

How are scope and pricing agreed?

A proposal follows the scope discussion and sets out deliverables, assumptions, exclusions, pricing, and review points. Small businesses and nonprofits can ask about special pricing and services tailored to their organization. The arrangement is agreed individually before work begins.

What will I receive at handover?

The proposal identifies the software and handover materials included in the engagement. Depending on scope, these can include setup instructions, content or operating guidance, verification results, and known limitations. Source-code delivery, ownership terms, third-party licenses, and account responsibilities are agreed explicitly.

What happens after I send an inquiry?

An inquiry starts a discussion about fit and scope; it does not reserve an appointment or a project start date. Dave reviews inquiries for fit, scope, and current availability. For a scheduled conversation, choose an available consultation time and complete the booking.

When can we meet, and when can work start?

Consultations are currently available on weekends, noon to 6 pm Mountain Time, subject to the booking calendar. Project start dates and delivery schedules are agreed individually after scope and availability are discussed.

What if the requirements change?

Changes are reviewed for their effect on scope, cost, and schedule before additional work is agreed. Review points provide a place to make those decisions explicitly.

Is ongoing support included?

Only when it is part of the agreed scope. Maintenance, enhancements, support coverage, and response expectations are discussed separately so the handover does not leave those responsibilities unclear.

What should I leave out of the first inquiry?

Do not send passwords, credentials, personal records, proprietary source code, or sensitive technical details. A high-level description is enough. An appropriate way to exchange project material can be agreed after the initial conversation.

Privacy information

Start with a conversation

A clear next step
for your next idea.

Tell us what you want to improve. We will help define what comes next.

Discuss your project