Approved operating record
FIRM DNA — AiStarDev LLC — AI deployment practice
What we are
We don't call ourselves an AI agency. Too many of them sell strategy decks and nothing ever ships.
We build one working system in thirty days, for a fixed price, with the number it has to hit written into the contract.
Most AI projects die before production. Not because the technology fails—because nobody agreed what “working” meant, the tool never got wired into how people actually do the job, and six months later there's a demo nobody uses.
Our clients don't need convincing that AI works. They need one thing to actually go live.
Who we work with
Companies with one specific, repetitive, high-volume job and someone inside who feels the cost of it every week.
Examples of a good fit:
- A retailer answering 3,000 support tickets a month, where two staff spend their days on “where is my order”
- A finance team keying 800 supplier invoices a week by hand into their accounting system
- An operations team where every new hire asks the same forty questions, and a senior person answers them all
Three questions we ask in the first call:
- Which job? Name it.
- Who owns it? Someone has to feel the pain and have the authority to change it.
- What number moves? Hours saved, tickets deflected, invoices per day—pick one.
If a client can't answer all three, we're not ready to quote. You can't put a fixed price on a vague problem.
Where we may not be the right fit
Strategy-only engagements. Our work focuses on implementing and operationalizing defined AI use cases. For standalone roadmaps, assessments, or capability frameworks, we recommend a specialist partner.
Projects that cannot begin with paid discovery. We start with a focused scoping week to confirm requirements, risks, and the delivery plan. If the project continues, that fee is credited toward the engagement.
Regulated-data projects without an agreed compliance plan. Work involving PHI, PII, or other regulated information begins only after responsibilities, safeguards, and processing boundaries are documented.
Organizations requiring full procurement before an initial discovery call. Our current service model is designed for teams that can begin with a focused fit conversation before completing formal contracting and security reviews.
How we price
Fixed scope. Fixed price. Thirty days. A monthly retainer attached from the start.
Why fixed price: our clients have usually been burned by an hourly engagement that ran long and ended with no working system. A fixed price means the overrun is our problem, not theirs. That's uncomfortable for us, and it's exactly why it sells.
Why a retainer, always: an AI system doesn't sit still. Models get updated. Prompts stop working the way they did. New edge cases show up in month three. A project without a retainer is a system nobody maintains, and we'd rather turn down the project.
If the budget doesn't fit, we cut the scope—not the price. A client with $25,000 and a $35,000 problem gets a smaller first system, not a discount on a big one.
The line we hold
We put the number in the contract. We don't sign without one.
A real example of what that looks like:
“The system will draft replies to at least 60% of Tier-1 support tickets, measured over 30 days running alongside the human team before anything goes live.”
That sentence is in the agreement. Agreed before we start. Measured before cutover.
This is uncomfortable and we mean it to be. It means we can fail in a way the client can point at. There's no reframing it in a final presentation. Most firms in our space won't do this, and the ones that won't are competing with us on exactly this point.
We do it because the alternative is the thing our clients already distrust. Someone who got burned once isn't buying capability—they're buying proof that a person will stand behind a result. Dropping the number would make contracts easier to sign and destroy the reason we win them.
And when a client can't name a number, that's not a contract problem. It means the job isn't clear enough yet, so we go back to discovery instead of forward to a signature.
What we can show
We build our own products on the same platform we sell.
Our production AI support system publishes its test results—including the cases it gets wrong. Every reply it writes shows which help article it came from and how confident it is. Below a threshold it hands the ticket to a human instead of guessing. Code doesn't ship if the tests don't pass.
Same tests, same handoff rules, same definition of done that we use on client work.
We'd rather show you something we run ourselves than a case study about someone else.
How we talk
Plainly. We use numbers instead of adjectives, and we name our own limits before a client finds them. Where a competitor does something better than us, we say so—partly because it's true, and mostly because someone who catches you overstating one thing stops believing the rest.
The other six sections
| Section | Record | What it decides |
|---|---|---|
| 2 | Who we're looking for | Company size, the three qualifying questions, and the red flags we check on every enquiry |
| 3 | What we sell | The three packages, what's in each, and what moves a client between them |
| 4 | How we deliver | Discovery, build, run alongside humans, go live, retainer—and the check at each step |
| 5 | What “done” means | Test coverage required, handoff rules, and what has to be true before we call it finished |
| 6 | Where we stop | Data handling, where it gets deployed, and the conditions under which we halt work |
| 7 | Commercial rules | Deposits, change requests, scope creep, and what we say no to |