Ask a question

Custom software, built by one expert directing AI agents

Who carries each risk

In a usual engagement, most of these risks stay with you. Here, 4 stay with you, 2 are shared and 10 move to the lab.

Typical pattern, not a named provider, and not market data.Gold marks a risk the lab now carries. Two are shared, for reasons the register gives.

Who worries about this?

Register · rows 01 to 04

The four transfers, written as clauses

Each promise has a trigger, both outcomes, and what you hold if it goes wrong. Every row has a permanent address, so you can paste #R-03 into an email to a partner or an investor.

last reviewed owner: the lab

  1. R-01
    Carried byThe lab

    You wait months before you see anything.Will I wait months before I see anything?

    What usually happens

    Weeks of documents and meetings come before the first working screen.

    What we do

    A working prototype in 3 days: every screen your users will touch, on sample data, on a link you can open.In 3 days you get a working version you can click through, before we build the real thing.

    If it is right

    The prototype and its scope list become the agreed scope and the fixed price.

    If it is wrong

    You change it, and nothing is built until you agree the new scope list.

    Residual risk

    Three days needs a few hours of your time and the files you already have. Nothing is due for the prototype.

    Evidence you can check

    The prototype link itself, which you use before you sign anything.

  2. R-02
    Carried byThe lab

    The build runs late.What if it takes far longer than promised?

    What usually happens

    Dates often slip, and the extra time is billed at the same rate as the planned time.

    What we do

    A full production system in 1 month, for any application, built to the scope list the prototype fixed.The finished system is ready in 1 month, whatever the application.

    If it is ready in the month

    You run your acceptance test against the scope list.

    If the month runs over

    The price does not move, because it was fixed at sign-off and nothing more is invoiced until your test passes.

    Residual risk

    The month assumes your data and decisions arrive when the scope list says.

    Evidence you can check

    A working link that updates every few days during the month, so nothing is a surprise at the end.

  3. R-03
    Carried byThe lab

    You pay for software that does not work.What if I pay for something that does not work?

    What usually happens

    A deposit before the build, invoices at milestones during it, and a final payment on delivery, often before your own testing is finished.

    What we do

    At sign-off you make a set-up payment of ₹20K-50K for the AI usage and servers of your build, deducted from the fixed price. Nothing else is invoiced until you run your acceptance test (UAT) against the scope list and it passes.You make a small set-up payment when you agree the prototype. The rest you pay only after you have checked that it works, with nothing along the way.

    If it passes

    You pay the rest of the fixed price agreed at prototype sign-off, once.

    If it does not

    We fix it and you test again, and there are no payments along the way.

    Residual risk

    The set-up payment is made before your test. Until the test passes, that payment is your exposure, and the rest of the price is ours to carry. A test only catches what it checks, so we help you write it (see Y-01).

    Evidence you can check

    The test list itself, signed off with the prototype before any build starts.

  4. R-04
    Carried byThe lab

    Every change reopens the price.What if every change I ask for brings a surprise bill?

    What usually happens

    The estimate is reopened with each change, and the final bill is known only at the end.

    What we do

    Anything beyond the scope the prototype fixed is a change request, priced as a fixed item before work starts.Anything new is written down with its own fixed price, and nothing starts until you say yes.

    If you say yes

    It is added to the build at the price written down.

    If you say no

    Nothing changes, and nothing is billed.

    Residual risk

    Bugs found in your acceptance test are ours to fix, and new wishes are change requests, so agree that line at sign-off.

    Evidence you can check

    A written line, its fixed price and your yes, before any work on it.

Register · R-11 in detail · how we can wait for the rest

Why the lab can carry this

It costs about a fifth of a conventional build. A careful buyer then asks the obvious question: how can a lab that charges less also afford to wait for the rest of the price until your test passes?

A full team for months
One expert directing AI agents
Your price is fixed in writing at prototype sign-off, before the build starts. Illustration, not a quote.

In plain words A normal software project pays a large team for months, and much of that time goes on coordinating and waiting. We use one expert and a team of AI agents that write and test the software at the same time. Low running costs, covered by the set-up payment, are what let us wait for the rest.

Where the saving comes from

  1. One expert directs and reviews every change, instead of a pyramid of roles and the meetings between them.
  2. Agents do the volume work in parallel, so the calendar holds more building and less waiting.
  3. Tests are written with the code and run on every change, so there is no separate testing team at the end.
  4. No account managers or hand-offs. The security review and hosting sit inside the engagement, not on top of it.

The saving is not a discount. It is the waiting you no longer pay for. The same low cost base is why we can wait for your acceptance test before we invoice the rest: the set-up payment covers the AI usage and servers in the meantime.

Register · rows 05 to 12

Eight more risks, from security to who is behind it

Security, testing, the code the agents wrote, ownership, support, price, and the two rows a one-expert lab has to answer honestly. One sentence per cell. Engineers can open Go deeper on any row.

Risk

Nobody tests security before launch.Will anyone try to break in before it goes live?

What usually happens

Security testing is often bought separately, late, or not at all.

What we do

A security review runs before every production deployment, with a deliberate attempt to break in, and each finding is reproduced, fixed and guarded by a test.Before it goes live, we try to break in the way an intruder would, and fix what we find.

Carried byThe lab
Residual risk

No test finds everything, so the report lists what remains open, with an owner, the risk it carries and a mitigation plan. The review is our own, not an independent certified audit.

Evidence you can check

26 Aug 2026: six access paths found, two reproduced live, all fixed. source: the worked example

Go deeper: the security review

Scope: authentication and sessions; tenant isolation enforced in the database; authorisation on every route (is this record yours, not only are you logged in); uploads, URL ingestion, tokens and oversized bodies; key separation; rate limits on public endpoints; pinned dependencies; headers and exposed ports.

The six findings on our own product: a cancel that took an id and no owner; uploaded HTML served into an unsandboxed frame; password hashing on the event loop; URL ingestion with no address check; a malformed bearer token answering 500; one key doing both session-signing and secret-sealing. Each was fixed with a test that failed before the fix.

Risk

The code was never properly tested.How do I know it was checked properly?

What usually happens

Testing is a phase at the end, and the first thing squeezed when a date slips.

What we do

Tests are written with the code and run on every change, and agents play your users with the questions people actually type.Every change is checked by machine before a person looks at it.

Carried byThe lab
Residual risk

Tests prove the cases someone thought of, which is why your acceptance test has the last word.

Evidence you can check

14 Sep 2026: backend suite 1,685 of 1,685 passing, calendar service 48 of 48. source: the worked example

Go deeper: how tests are written

Tests go in the same commit as the change. A test that failed before the fix and passes after it is the normal shape. End-to-end tests are agents playing real users: natural questions, typos, mixed languages.

Quality is reported with the lower number. On a 108-question corpus the grader scored 71 percent and a hand read found 93 of 108 substantively right; the gap was answers in Hinglish marked wrong by a substring grader.

Risk

Agents wrote code nobody read.Did a person actually check what the AI wrote?

What usually happens

Generated code is merged because it looks plausible and its own tests pass.

What we do

The expert reads every change, and a finding is acted on when it is reproduced, not when it is argued.The expert reads every piece of work the AI agents produce before it is kept.

Carried byThe lab
Residual risk

One reviewer can miss things, so tests, database constraints and the security review sit behind the review.

Evidence you can check

219 commits from 13 Aug to 25 Sep 2026 by one author; tests go in the same commit as the change; walkthroughs on request.

Go deeper: how agents are directed

A design pass comes first: two sentences for a small change, a numbered design document for a subsystem. Independent work items go to background agents in parallel, each with the design, the conventions and the tests it must keep green.

Rules live in the database, not only in the application: EXCLUDE for overlapping time ranges, composite foreign keys for same-client invariants, row-level security forced on every tenant table, and an app role that cannot bypass it. Deployment needs a human's click.

On 17 Jul 2026 a 57-agent adversarial audit of our strategy foundry raised 50 findings: 44 confirmed, 6 refuted, 15 fixed the same day.

Risk

You are locked in to the builder.Will I be stuck with you for good?

What usually happens

The code, the hosting accounts or the know-how stay with the vendor.

What we do

You own the code on payment, and receive the repository with its tests, the documentation, the runbooks, the build log, and the backup and restore procedure.Once you have paid, everything is yours, with the instructions another team would need to run it.

Carried byThe lab
Residual risk

Reused components keep their own licences.

Evidence you can check

Run the test suite yourself: it is in the repository you receive, with instructions for Linux.

Go deeper: the hand-over

Hosting can be cloud, region-resident cloud, private or on-premises, or fully air-gapped. Your data is yours, and it is not used to train anything.

Risk

One expert is a single point of failure.What happens if the one person behind it is unavailable?

What usually happens

A larger provider can move people in, though they start from whatever was written down.

What we do

We are training more experts, and there are already people who run production work with the digital twin, a written memory of how the expert works and what has been decided. If work stops mid-build the rest of the price is not due, and after launch the repository, runbooks and restore procedure are already yours.We are training more experts, and other people already run production work from a written memory of how the expert works. If we stop mid-build, you do not owe the rest. If we stop later, everything needed to run it is already in your hands.

Carried byShared
Residual risk

Until continuity terms are confirmed, part of this risk is yours.

Evidence you can check

A walkthrough of a runbook and the restore procedure, on request.

Risk

Nobody is there after launch.Who helps when something stops working?

What usually happens

Support is a separate contract, priced once you already depend on the system.

What we do

Hosting and ongoing support are free for the first 6 months, with encrypted nightly backups kept offsite and a rehearsed restore.We keep it running and look after it, free for the first 6 months.

Carried byThe lab
Residual risk

Response times are not yet published. After the first 6 months, the price for maintenance and the production server starts from ₹3K a month.

Evidence you can check

On our own product: nightly encrypted backups, an offsite mirror, and a rehearsed restore.

Risk

You overpay for what you get.Am I paying too much?

What usually happens

Headcount and calendar time are billed, including the days spent waiting.

What we do

About a fifth of the cost of a conventional build, fixed after the prototype. After a set-up payment at sign-off, the rest is paid once, after your test passes.It costs about a fifth of what a usual software project costs, and you know the price before the build starts.

Carried byThe lab
Residual risk

Your team's time and third-party fees do not shrink: see Y-02 and Y-03.

Evidence you can check

The fixed price in writing before the build starts, and why the lab can carry this.

Risk

You cannot check who is behind it.How do I know who I am dealing with?

What usually happens

You judge a provider by its name, its size and its client list.

What we do

The promises are in the contract, so trust rests on your acceptance test, not on a reputation.You do not have to take our word for anything: apart from the set-up payment, you pay only when your own check passes.

Carried byShared
Residual risk

You meet the expert on the scoping call, and their name is on your contract.

Evidence you can check

The service record below, and the contract you sign.

Service record

Role
Directs the agents and signs off every release
Experience
A decade of domain experience
Name
Withheld by design
Answers to
Your acceptance test

We publish the method, not the person, because the method is what you are buying.

Register · rows Y-01 to Y-04 · risks that stay with you

We cannot carry these, and will not pretend to

  • Y-01Carried byYou

    Writing the acceptance test with care

    Why it stays

    A test only catches what it checks. We help you write the list, and you decide what done looks like.

  • Y-02Carried byYou

    Your team's time

    Why it stays

    Plan for a few hours in the first 3 days and a few days at the end of the month for your acceptance test. This does not shrink.

  • Y-03Carried byYou

    Third-party fees

    Why it stays

    In production, AI models (LLMs), voice models, SMS and WhatsApp charges are passed on at cost, with nothing marked up. They do not shrink either.

  • Y-04Carried byYou

    Messy legacy data

    Why it stays

    Where the old data is the problem, we scope it during the 3-day prototype and price it separately if it is large.

Evidence · controls behind the rows

Controls, tested on our own product

We do not name clients, so the evidence comes from a product we built and own: a booking and enquiry receptionist that works on WhatsApp, now in early access. Each log line is tagged with the register row it evidences.

How we build: six controls, in order

  1. 1
    Design pass. Two sentences for a small change, a numbered design document for a subsystem.
  2. 2
    Agents in parallel. Independent work goes to AI agents at the same time, each with the design, the conventions and the tests it must keep green.
  3. 3
    Every change reviewed. One expert reads every change and accepts a finding only when it is reproduced.
  4. 4
    Automated tests. Written with the code, run on every change, with agents playing real users end to end.
  5. 5
    Security review. Before every production deployment, on the repository and the running system.
  6. 6
    Deploy, host, hand over. Deployment needs a human's click. Then we host it, support it and hand everything over (see R-08).

In plain words One expert plans the work. A team of AI agents builds it at the same time. The expert checks every piece before it is kept, machines test it on every change, and before it goes live we try to break in. Then we host it, look after it, and hand you everything.

Control-test log

  1. First commit. One author.
  2. Security review: six access paths, two reproduced against a live tenant. All fixed that week, each with a test that failed before.R-05
  3. Go-live audit: 33 findings (6 blockers, 13 high, 12 medium, 2 low). All closed.R-05 R-06
  4. Re-audit over roughly 32,000 changed lines in four lanes. The audit's own verdict: "still not ready, for fewer reasons". Backend suite 1,685 of 1,685, calendar service 48 of 48. Deployed.R-06
  5. 219 commits since 13 Aug, one author. Early access open.R-07
  6. measured8 concurrent bookings for one slot: exactly 1 wins, held by a Postgres EXCLUDE constraint, not by the model.R-06 R-07

the audits in this log, as a worked example

Proof arrives with payment

Risks retired in the field

A record appears only after a client's acceptance test has passed, they have paid, and they have approved the wording. Clients are attributed by role and sector, never by name.

  • Specimen

    What a record holds

    Accepted
    [date accepted]
    Sector
    [sector]
    Built
    [what was built, one line]
    Retired
    [R-03]
    Signed by
    [role, never a name]

    No client data. Structure only.

Register · outside scope

Risks we decline

A register that accepts every risk is not a register. These are engagements we would turn down, and who serves them better.

We turn these down

  • A fixed-price build where nobody can yet say what done looks like, so no acceptance test can be written.
  • Supplying people by the hour to join another team.

Who fits them better

  • Discovery first, which is free, until it is clear what done looks like. We offer that ourselves.
  • A staffing firm, for capacity by the hour.

First step

Name your risk

Tell us in a sentence. We reply with the row that answers it, or say plainly that the register does not.

Opens an email to hello@aikameva.in with your sentence and the row you chose. Nothing is sent until you press send.

A 30-minute scoping call

To share with a partner or an investor