Founder voice
Most agencies hide pricing and run bespoke proposals. We publish the menu. Here is what that costs us, what it earns us, and why we think it is the right call for a founder-led services company.
Every agency website does the same thing in roughly the same place. Somewhere on the services page, where you would expect a number, there is a button instead. Get in touch. Request a proposal. Book a discovery call. The friction is on purpose. The pricing conversation is a sales asset, not a piece of information, and agencies have decided you should have to earn it.
We publish ours. The four offerings, the price bands, what is included, what is not, all visible from the homepage. This piece is about why.
Three things, mostly.
The first is the buyer's time. A founder evaluating five agencies for a mobile AI integration project has to run five discovery calls, sit through five different qualification sequences, and assemble five different bespoke proposals over four to six weeks before they can do an apples-to-apples comparison. Most do not make it that far. They pick two or three, get tired, and choose the one whose proposal arrived first.
The second is the agency's time. Every discovery call that does not convert is a sunk cost. We have run discovery calls that turned out to be tire-kicking; we have run them where it became clear in the first 15 minutes that the project budget was less than half our minimum engagement. Hidden pricing front-loads that filtering onto a call. Published pricing front-loads it onto the website, which we wrote once and now serves 24 hours a day.
The third is the trust gap. Hidden pricing creates the impression that the price is negotiable, which creates the impression that the price is bespoke, which creates the impression that the agency might be charging the next buyer something different from what they charged the previous one. That impression is sometimes accurate. Even when it is not, the impression is itself a tax on the relationship.
When we sat down to lock the pricing model for Inseed, the question we asked was not "what would maximize a single deal." It was "what would the kind of buyer we want to work with prefer." Our target buyer is a founder or a CTO. They have run their own pricing exercises for their own products. They know that bespoke-everything is a sign of an immature offering, not a sophisticated one. They have already decided that they would rather skip the negotiation theatre and get to the work.
Publishing the price is also a forcing function on us. It forces us to actually understand what we sell. The Mobile App Audit is a one-week engagement, between $5,000 and $8,000, with a written report, a 60-minute walkthrough, and 30 days of follow-up. That is not a phrase we use in sales calls. That is a product. The discipline of writing that down, in a way that holds up across many engagements, is the same discipline that makes us better at delivering it.
It also makes the audit fee credit toward a larger engagement easier to talk about. The audit is $5,000 to $8,000. If you sign a larger engagement with us within 30 days, the audit fee credits toward it. That is a sentence I can say on a call. It is a sentence the buyer can verify on the website. It is a sentence that does not require either of us to negotiate.
Some real things.
We lose deals to agencies that price below us. A buyer who needs a $10,000 mobile build is not a buyer for our $25,000-to-$75,000 MVP Build, and they will find an agency that fits. That is fine; we would rather they find one quickly than spend three weeks discovering it through us.
We lose flexibility on the upper end. A genuinely complex MVP Build for a tightly regulated industry might be worth $120,000 to a buyer and to us, and our published band of $25K to $75K caps it lower than that. We handle this with a footnote: the band covers the typical case; custom engagements are scoped separately. So far this has cost us less than the negotiating room we gain elsewhere.
We lose a subset of high-end enterprise buyers who are uncomfortable with a vendor that publishes prices. Enterprise procurement is wired around RFPs and bespoke quotes. We are not optimizing for that buyer. The buyers we want, founders and CTOs of SMBs at $100K and up in annual revenue, do not need that procurement layer.
The buyer who shows up on a discovery call has already read the prices and is calling because they fit. The call is about fit on the work, not on the budget. That changes the shape of the conversation, in our favor and in the buyer's favor.
It also earns us speed. Most engagements we sign go from first email to signed contract in under two weeks. The published pricing is not the only reason for that; the productized scope of each offering helps too. But the price visibility removes the longest stretch of the proposal cycle most agencies put themselves through.
The other thing it earns us, which I did not expect when we started, is referrals. Buyers tell other buyers about us specifically because they appreciated being able to see what we cost. The phrase that keeps coming back is "they made it easy."
Published pricing is not the right call for every services company. If your work is genuinely bespoke each time, if your buyers are enterprise procurement teams, if the value of what you sell varies more than 5x across engagements: publishing the price will hurt you. You should run bespoke quotes.
For us, the work is productized enough that a price band captures most of the variation. We are founder-led, which means I personally do the scoping and I personally feel the cost of the discovery calls we run. We are small enough that every discovery call I sit on is one I am not on a delivery call for. The economics of publishing the price lean strongly in our favor.
If you have run your own pricing exercise and you are wondering whether to publish or hide: think about who your buyer is, not what the rest of your industry does. The rest of our industry hides prices. Our buyers prefer that we do not.
Shuhel Khan is the founder of Inseed. We work on AI integrations into existing mobile apps, AI-native MVP builds, and mobile development for web-first companies. Last revised 2026-05-13.
Keep reading
Integration patterns
A working formula and a worked example for forecasting monthly token cost on a mobile AI feature, so the model bill does not surprise your finance team in quarter one.
Read postEngineering
The three production failures we have seen most often when teams wire an LLM into a React Native app. What goes wrong, why, and the engineering pattern that prevents each one.
Read postThe audit is one week. Written, costed, and sized to fit on the desk of whoever is signing off.
Book your audit