Skip to content

How we work

Reduce uncertainty before increasing spend.

The process exists so that money is spent in proportion to evidence. Commitments stay small while uncertainty is high and grow only as it falls.

01Step

Problem submission

You send what exists today. A two-page problem description is a valid starting point, and so is a formal RFP with attachments. We do not require a template, and the material below helps the review go faster.

Problem Requirement Documents RFP / RFQ Constraints Deadline Existing systems Desired outcome

02Step

Initial triage

Before anything is priced, we review the submission for fit, missing information, the likely disciplines, and whether the next step should be an assessment, a prototype or a directly scoped build. You receive a short written response. This is triage, not a feasibility study or an engineering assessment; that work is the paid assessment and is sold as such.

Feasibility Missing information Likely engineering disciplines Major risks Whether ALIA Labs is appropriate

We will decline work where the requirement is outside our competence or where the economics do not justify the work.

03Step

Engagement structure

The engagement takes the shape the problem requires, not a standard package. A high-uncertainty problem starts small, usually as paid discovery or a prototype. A well-specified requirement can go straight to a fixed deliverable or milestone development. We propose a structure with the reasoning behind it, and you decide.

Discovery / feasibility Prototype Paid pilot Fixed deliverable Milestone development Integration Ongoing engineering

04Step

Acceptance criteria

Before major development starts, both sides write down what has to be true for the project to count as successful.

The criteria are agreed in writing and each one is testable. If a criterion cannot be measured, we rewrite it until it can be, or we drop it.

05Step

Delivery

You receive the work and the record of the work: the architecture, the code where code was written, the deployment, the test results, operating instructions, and a written list of known limitations. The goal is that your team can run and extend what we built without us in the room.

Architecture Code where applicable Deployment Testing Operating instructions Known limitations

06Step

Expansion

The engagement grows only after the evidence supports growth.

If a pilot meets its acceptance criteria, we propose the next stage. If it does not, the engagement ends, and you receive a written account of what was learned and why we stopped.

Start with the problem.