How to prepare for a 72-hour trial build so it is a fair test

A trial build is an experiment with a known price: you confirm a bounded, real piece of your development plan in writing, and within 72 hours you receive a working preview, a test report and tested, documented code as a package. The purpose is to measure the vendor on your own codebase before committing to the main project. Like any experiment, it produces a clear result only if it is set up properly. This guide covers what to do before the trial starts so that the 72 hours measure the vendor rather than your own preparation, and how to judge the delivery when it arrives. It is written around our engagement model, but the preparation is the same for any bounded pilot with a software vendor.

What the trial build is and is not

In our model the trial build is a genuine part of your development plan, not a demo and not a prototype. It is delivered as tested and documented code with full intellectual property transferred to you, at a fixed price of 9,900 euros, within 72 hours of your written confirmation of the scope. If you continue to the main project, the trial price is deducted in full. The first three clients receive it for 4,900 euros in exchange for a public reference. The complete sequence is on how it works.

It is not a free sample, a fixed-length engagement with whatever can be done in three days, or an open-ended exploration. The scope is fixed first; the clock starts when you confirm it; the deliverable is the confirmed scope.

Step one: choose the right piece

The choice of piece decides how much you learn. A good trial build piece has five properties:

• Real. It stays in production afterwards. Choosing a throwaway task wastes the price and tells you little about the vendor's handling of real constraints.
• Bounded. It can be described on two or three pages with acceptance criteria. If it cannot, it is a main-project scope, not a trial.
• Representative. It touches your actual codebase, conventions, tests and deployment path, so the vendor's ability to work with your real constraints is tested, not just their ability to write code.
• Independent. It does not depend on work that is still in progress on your side, on decisions not yet made, or on material that cannot be supplied in time.
• Judgeable. You can tell, from the delivery alone, whether it is good: tests, documented behaviour, code your team can read.

Typical good choices: a self-contained module with a clear interface, an integration with an external system, a well-defined migration, a reporting or export capability, the main workflow of a new product. Typical poor choices: "clean up the codebase", a feature whose requirements are still being debated, anything that needs production access.

Step two: write the scope

The written scope is what makes a fixed price and a 72-hour delivery possible. The format, covered fully in how to write a scope for a fixed-price quote, is brief for a trial build:

1. The outcome, in one or two sentences.
2. The capabilities it requires, as a short list.
3. What is explicitly out of scope, including the obvious adjacent things.
4. Acceptance criteria per capability: observable behaviour, required tests, required documentation.
5. Real constraints: stack, conventions, environments, compliance.
6. Inputs you will provide and when.

You send this, or a rougher version of it, through the request form. What comes back is a written scope description: our restatement of the piece, assumptions made explicit, acceptance criteria confirmed or refined, the fixed price and the delivery term. Read it carefully, because your written confirmation of that document starts the clock and fixes the deliverable. If anything is wrong or missing, say so in writing before confirming, not after.

Step three: prepare the material

The trial build is built in the vendor's own environment, so what the vendor receives from you has to be complete. In our model nothing of yours is connected to the work: AIPOS OÜ never connects to your code hosting, servers or cloud accounts, and existing code reaches us as a file package you send.

• Export the relevant code as a package: the modules the piece touches, the build configuration, and the tests that exist. A copy, not a credential.
• Make the build and tests runnable from the package. If a new engineer could not build and run the test suite from the README, fix that first. Otherwise the first hours of the trial are spent on your setup instead of your scope.
• State the conventions that matter: code style, commit message format, where documentation lives. If they are not written down, write the short version.
• Decide how you will integrate the delivery on your side: who reviews the package, who runs your CI on it, who merges it into your main line.

This is also most of the buyer-side checklist from security when AI agents build your software: supply copies, not access; keep production credentials out of it; run your own checks on what arrives.

Step four: prepare the environment and the data

If the piece depends on external systems, an API the product must call or a data format it must read, have the sandbox details, sample data and documentation ready before confirming the scope, with synthetic or masked data rather than production data. The work runs in AIPOS OÜ's own environment, so what it needs is specimens and specifications, not credentials to your infrastructure. Anything that cannot be supplied in time should move the piece's boundary, in writing, before confirmation.

Step five: name the decision-maker

Within the 72 hours, written questions may arise: an ambiguity in the scope, a choice between two reasonable interpretations, a missing input. Someone on your side must be able to answer in writing, quickly, and with authority. Name that person in the scope, with an expected response time. All communication is written, which means the questions and answers are on the record and do not require anyone to be available for a call; they do require someone to be reading.

The same person should confirm the scope and accept the delivery, so that what was agreed and what was accepted are judged by the same eyes.

Step six: decide in advance how you will judge the delivery

Write down, before the trial starts, what a pass looks like. For most buyers it is some combination of:

• Acceptance criteria met. Every criterion in the confirmed scope is demonstrably satisfied.
• Tests. An automated suite exists, passes, and covers the behaviours the scope named.
• Code quality. Your engineers can read the commits, follow the structure, and would be comfortable extending it.
• Documentation. The architecture and the delivered behaviour are written down well enough for a new team member.
• Process. The written scope description was accurate, questions were sensible, the daily reports matched what arrived, and nothing was requested that had not been agreed.
• Speed. The delivery arrived within 72 hours of your confirmation.

Deciding the bar in advance prevents two failure modes: moving the goalposts after a good delivery because the decision to continue feels large, and accepting a weak delivery because the price was already paid. The broader evaluation questions are in how to evaluate an autonomous AI software development vendor.

During the 72 hours

Your job is small and specific: read the daily progress report, answer written questions promptly, and resist the temptation to add scope. Anything you think of during the trial goes into the list for the main project, where it is scoped and priced in writing. Adding it to the trial changes the experiment.

After the delivery

Review against the bar you wrote down: try the product on the password-protected preview link, run the delivered package and its tests, read the test report. If the delivery passes, you receive a written quote for the main project: the whole confirmed scope at one fixed price, with the trial price deducted in full, delivered in days and weeks with every change tested and committed. If it does not pass, you have learned so at a known, bounded cost, you keep the code and the intellectual property, and you have a clear record of why. Either way, the result is evidence rather than a sales conversation.

A preparation checklist

• The piece is real, bounded, representative, independent and judgeable.
• A scope with outcomes, exclusions, acceptance criteria, constraints and inputs is written.
• The written scope description has been read and confirmed in writing, with corrections made before confirmation.
• The relevant code is exported as a package; build and tests run from it; conventions are stated; your side knows who reviews and integrates the delivery.
• Sandbox details, sample data and specifications are ready; no production data or credentials are involved.
• One named person answers written questions within a stated time and accepts the delivery.
• The pass criteria are written down before the clock starts.

With this done, the 72 hours measure what you want them to measure: whether this vendor, on your code, under your constraints, delivers what it promised. The request form is where it starts; the guides cover the surrounding decisions for each situation.

Frequently asked questions