I tackle projects of various sizes; from small tasks with a well defined scope, to larger builds that require gathering more information.
When a project has real unknowns, a paid discovery always comes first. It costs money up front and still works out cheaper. Here’s why.
A fixed price with no discovery is a bet
Say you ask me to connect your site to a vendor’s system. If I haven’t worked with your site before, I don’t know what I’m working with.
Even if I’m familiar with your site, third-party integrations come with plenty of unknowns. I don’t know if their documentation is current, whether the access you need still exists, or whether it’s a one-day job or a multi-week build.
Quote a fixed price anyway and I’m betting. I pad the number to cover everything that might go wrong, and you overpay for the easy version. Or I quote tight, hit a wall I couldn’t see, and ask for more money halfway through.
Either way: you pay for risk that never showed up, or you inherit the risk that did.
What discovery actually is
Discovery is a small, paid engagement where I do the looking before anyone commits to the build. I get into your site and the accounts, read the real documentation, and talk to the vendors who have to be involved. I find out what’s actually there instead of what the brief assumes.
You end up with two things: a written findings document, and a build proposal with a real number on it. The unknowns are either turned into known quantities or flagged honestly as the things still outside anyone’s control.
Most discovery is a flat fee, scaled to the scope of what needs investigating.
When a project doesn’t need it
Plenty don’t. If the work is small, well defined, and close to something I’ve built before, I’ll just quote it. A landing page. A fix I can scope by looking at the site. A feature with no third-party system in the middle. There’s nothing to discover, so I don’t charge you to discover it.
Discovery earns its place when the unknowns are real: a vendor I haven’t worked with, access I can’t see until I’m inside, a problem whose cause isn’t obvious yet. The wider the gap between what the brief says and what I can actually confirm, the more it pays for itself.
It’s credited toward the project
If you move forward with the build, the discovery cost comes off the project total. You’re not paying twice. You pay for the investigation once, and that money applies to the work.
So the real question isn’t why discovery costs extra. It usually doesn’t. It’s whether you’d rather start with a price I made up or one I can stand behind.
What you get even if you walk away
Sometimes discovery turns up something that changes the plan. The integration isn’t possible the way you pictured it. The vendor charges for the access the whole thing depends on. The real problem is somewhere other than where you thought.
Better to spend a few hundred dollars finding that out up front than partway through a full build. You keep the findings document either way. Take it to a different developer if you want. You’re walking in with facts instead of a guess.
