Insights from a Daily Improvise Founder Conversation | November 5, 2026
Estimating a software project is relatively straightforward when the requirements are clear, the technology is familiar, and the scope is well-defined.
But what happens when you don’t know exactly what needs to be built, how the technology will work, or how long development will take?
This was one of the questions explored during our November 5 Daily Improvise founder conversation.
Founders from different industries and backgrounds came together to share their experiences, challenge assumptions, and discuss how they approach uncertainty while building businesses.
Why Is Estimating Software Projects So Difficult?
Consider a platform that needs to monitor social media, identify potential business opportunities, initiate conversations, and arrange meetings.
It sounds like a straightforward automation product.
But the complexity becomes clearer when you start examining the requirements.
- Which social media platforms need to be supported?
- Do those platforms provide suitable APIs?
- What happens when API access is restricted?
- Will separate integrations or crawling mechanisms be required?
- How will the system handle platform changes and rate limits?
- How much automation is technically and legally feasible?
The challenge isn’t simply estimating development hours. It’s understanding what is technically possible before committing to a timeline and budget.
1. Technical Uncertainty Can Change the Entire Estimate
One important takeaway from the discussion was that different platforms can introduce very different technical challenges.
An integration that works well with one platform may not work with another.
API restrictions, authentication requirements, rate limits, data availability, and platform policies can significantly affect the implementation approach.
The lesson: Don’t estimate the entire project based on assumptions that haven’t been validated.
Identify the biggest technical risks first. Test them through small proof-of-concept exercises before committing to a full development estimate.
2. Break the Project Into Smaller Milestones
Instead of estimating an entire product as one large project, divide it into manageable stages.
For example:
- Discovery: Understand business requirements and technical feasibility.
- Proof of concept: Validate the most uncertain integrations and workflows.
- MVP: Build the essential functionality.
- Expansion: Add more integrations, automation, and advanced features.
- Optimization: Improve reliability, performance, and scalability.
This approach gives everyone better visibility into progress, risks, costs, and timelines.
It also creates opportunities to revisit assumptions before moving into the next stage.
3. Choose a Commercial Model That Reflects the Uncertainty
The discussion also explored different ways of structuring commercial agreements.
Two possibilities were considered:
Time-based billing
The client pays for development effort over an agreed period. This can work when requirements are evolving and the scope cannot be accurately fixed upfront.
Revenue sharing
The development partner participates in the revenue generated by the product. While this can align incentives, it also introduces questions around ownership, revenue attribution, responsibilities, and long-term commitment.
Neither model is universally better.
The right choice depends on project ownership, financial risk, decision-making authority, and the level of uncertainty involved.
Importantly, revenue sharing should not be treated as a substitute for a clear agreement on responsibilities and compensation.
4. Don’t Confuse an Estimate With a Commitment
An estimate is based on available information and assumptions.
A commitment is a promise to deliver within agreed conditions.
When requirements are uncertain, presenting a precise timeline and fixed cost can create unrealistic expectations.
A better approach is to communicate:
- What is currently understood.
- What assumptions the estimate depends on.
- Which risks could change the timeline.
- What needs further validation.
- When a more reliable estimate will be available.
Transparency at the beginning can prevent difficult conversations later.
5. Discovery Is Part of Building the Product
One of the biggest mistakes in software development is treating discovery as time spent before actual development begins.
In uncertain projects, discovery is essential engineering work.
It helps identify technical limitations, validate assumptions, understand dependencies, and avoid investing heavily in an approach that may not work.
Spending time validating the unknowns can save significantly more time and money during development.
What Founders Can Take Away
The conversation reinforced a few practical principles:
- Don’t promise timelines before validating technical feasibility.
- Identify the riskiest assumptions early.
- Break large projects into smaller, measurable milestones.
- Choose commercial models that reflect the actual risks.
- Communicate uncertainty instead of hiding it behind precise numbers.
There isn’t always a perfect estimate at the beginning of a project.
Sometimes, the most responsible answer is to explain what you don’t know yet and define how you will find out.
About Daily Improvise
Daily Improvise is an invite-only global founder community built around honest conversations, shared experiences, and meaningful connections.
Through regular online founder conversations, entrepreneurs come together to discuss the realities of building and running businesses, exchange perspectives, and learn from one another.
No unsolicited pitching. No transactional networking. Just better conversations.
A smaller room. Better conversations. Stronger connections.
Interested in joining a future conversation?