Find the limitsbefore they find you.
Every Amtal engagement starts here. Discovery is where the unknowns are engineered out of the project. It ends with a fixed scope, price, and deadline, in writing, and a decision that is yours to make.
Nobody can pricewhat nobody has examined.
The integration that was never documented. The workflow that lives in one person's head. The load nobody measured. Each one becomes a surprise in the build, and surprises are what turn estimates into overruns. The research on project delivery says the same thing in numbers.
Our name is a rule about finding limits and defects on purpose, before they are found by accident. Discovery is that rule applied to the project itself, before a line of production code exists and while being wrong is still cheap.
By the numbers
- Across 2,841 project professionals surveyed, roughly three in ten projects ran over budget and four in ten ran late, even in organizations that rate their own project practice highly. Project Management Institute, Pulse of the Profession 2025
- 26% of IT projects were not delivered on time, and IT teams spend 36% of their time designing, building, and testing custom integrations. Salesforce / MuleSoft, 2026 Connectivity Benchmark
Six placesthe surprises hide.
These are where the surprises that turn estimates into overruns tend to hide. So this is where we look first, and hardest.
01
The workflow as it is actually done
Not the documented version. The real one, learned by sitting with the people who do the work and watching where it bends.
02
Every integration, and where the truth really lives
Which system is the record, which ones copy it, where the copies disagree, and what happens when one of them is down.
03
Load, in numbers
Not “a lot.” How many, how fast, at what peak, growing at what rate. The numbers the architecture is sized against, and then deliberately exceeded in testing.
04
Security and compliance requirements
HIPAA, PCI, audit trails, data residency: the constraints that have to be architecture, not a checklist at the end.
05
The existing system, if there is one
We read it before we judge it. What is worth keeping, what is quietly failing, and what has to go first.
06
The decisions that will be expensive to reverse
Data model, platform, integration boundaries. These get the most scrutiny because they get the fewest second chances.
Facts first.Then the plan.
01
Working sessions with the people who do the work
Not only the sponsors. The front desk, the dispatcher, the analyst rebuilding the report by hand. The people who know where it actually breaks.
02
We read the system before we judge it
Code, data, integrations, infrastructure. Assumptions about the current state are where overruns tend to start; we replace them with facts.
03
The riskiest assumption gets tested first
If one integration, one migration, or one performance target could sink the project, we prove it out now, while being wrong is still cheap.
04
Then we write it down
Scope, architecture, risks, milestones, price, deadline. In plain language, with the reasoning shown, so the decision is made on facts.
A price you cantake to the board.
A fixed scope, price, and deadline, in writing and treated as promises
The architecture, and an integration map of every system involved
A risk register: what could go wrong, how likely it is, and what we do about it
A milestone plan that schedules the acute pain first
A written recommendation: build, build less, or start with something off the shelf, with the reasoning shown
All of it yours to keep, whether or not you build with us
Then you decide
The decision to proceed is yours.
If you build with us, the price and the deadline are the ones in the document. We treat them as promises, and a start is a promise to finish.
If a smaller build, or an existing tool, would get you the result for less, the document says that too. The plan exists to get you the result, not to sell you the build. And it is yours either way.
Start with a conversationWe agreewith most of it.
Buyers have been burned by fixed bids, and the objections are fair. Here is each one, and what in our process answers it.
“Fixed prices get padded.”
A price for unexamined work carries a buffer for everything nobody looked at. Discovery removes the unknowns that buffer pays for, so the number covers the work, not the fear.
“Every change turns into a fight.”
Only when the rule is unwritten. Ours is: swap a change for work of equal size, or price and schedule it before it starts. In writing, before the work, every time.
“Quality gets cut to protect the margin.”
The build ends with the system pushed past its limits on purpose, and you get the numbers in writing. Corners cut show up there, at our expense, rather than in production at yours.
“You freeze the scope before you have learned anything.”
Discovery is the learning. It ends with a recommendation, with the reasoning shown, and the decision stays yours.
“A fixed quote on day one is a red flag.”
It is. We will not give you one. The first conversation is free, and the number comes after Discovery, not before.
Tell us whereit's straining.
The platform, the CRM, the launch, the AI mandate: whatever is carrying more than it was built for. Your free consultation is a working session, not a sales call: honest questions and a point of view, not a brochure.
hello@amtal.dev- Response time
- Within one business day
- Engagements
- Open