Founders who stay close to their own sales calls learn what the company should build. Getting to $1M in revenue is a clear target, and the path there is a run of lessons about buyers, pilots and product.
Sales tells you what to build.
On October 15, Orchestra hosted a few dozen startup founders at its San Francisco office for a workshop on reaching the first million in revenue. Orchestra CEO Luis Manrique drew on building Orchestra and on his time as an early employee at other startups.
His view is that founders should stay in the room for early sales. A buyer deciding whether to invest forces specifics: which problems are worth fixing, how much work the fix takes, and what the buyer needs before trusting a young company. Each answer belongs in product decisions.
He has seen both sides. Before joining Gumloop as its second employee, he was its first enterprise customer, trying to make a new tool earn its place inside an existing company. A good demo was not the test. The test was whether the team could finish or improve real work with it.
Find what makes waiting expensive.
Buying from a startup asks a lot. The buyer has to assess an unfamiliar product, defend the choice to colleagues and managers, and depend on a vendor that may be smaller than their own department. If the current process is tolerable, even a valuable product is easy to postpone.
Luis often opens by asking a prospect to walk him through the last time the problem happened. The open question lets people share as much as they are comfortable with. A recent incident also gives the conversation something concrete to dig into: the work that stalled, who took on the fix, and what it cost to leave the issue alone.
At Orchestra, the same holds for evals and specialist models. A lower per-token price on a model page does not prove a buyer's product will work as well on it, so the improvement has to be measured on their workload before they commit.
Turn interest into a pilot.
A friendly meeting is not a commitment. A prospect who wants to cut the cost of serving customers can name its most expensive workloads and the quality it has to keep. Orchestra's part is to compare model results on that workload and agree on what an acceptable result looks like.
The goal of an early sale is a pilot. Agree on the work, let the client define success, and set the next steps if the pilot meets that bar. Give it a timeframe and a decision date. If the pilot is paid, write the price and the deliverable into the agreement.
Pilots surface the details that make or break a deal. Your contact may love the product and have no budget, or the team may agree on the problem but not on what a good result is. Finding this early lets you change the proposal or spend your time elsewhere. Follow-up should target the real blocker, because another demo will not fix a missing approver.
A clear no, with reasons, teaches more than a pipeline of pleasant conversations that never resolve.
Build from what you observe, not what clients request.
Building every requested feature turns a startup into a shop of custom projects. Ignoring requests leaves you defending a product people cannot use. At Gumloop, the usual starting point for a change was a process a client could not finish alone, followed by work to find the fix that helped the most clients.
Orchestra applies the same discipline. When a client asks for a specific model or capability, the team first asks what outcome they want. If the goal is lower cost at the same quality, Orchestra tests the cheapest way to meet that quality bar. Training a new model may be justified, but an existing model or a better prompt can sometimes do the job.
Hire for the bottleneck.
For Luis, cold outbound was the limit, and getting help with it freed time for client conversations. Before hiring, find where your process stalls. If you cannot get meetings with qualified buyers, you need reach. If you get meetings but no sales, more of the same meetings will not help.
Founders can hand off sales tasks, but they should keep direct access to the conversations that shape the business. The full essay ends with a plan for this week: pick one reachable buyer and build a specific proposal around a problem they already have.
Evaluate your workflows to see how Orchestra measures improvement on your own work.