What to Expect in the First 90 Days With a Software Development Partner

Choosing a software development partner is an important business decision, but signing the agreement often raises a new set of questions: What happens next? Who needs to be involved? When should you expect a roadmap? And how will you know the engagement is moving in the right direction? 

By day 90, you should have a validated understanding of the business problem, alignment among key stakeholders, an assessment of your current technology environment, a prioritized roadmap, agreed success measures, and clear expectations for decisions and communication. The goal is not to get developers writing code as quickly as possible. It is to create enough clarity to invest and move forward with confidence. 

What Should the First 90 Days Accomplish? 

The first 90 days should turn an initial business need into a shared, informed direction for what comes next. 

In conversations with business leaders, I often see organizations enter an engagement with a solution already in mind. They may believe they need a new application, a replacement for a legacy system, or an integration between platforms. Sometimes that direction holds up. Other times, discovery changes how the organization understands the problem. 

That is why I view the first 90 days less as onboarding and more as validation. A good software development process should help confirm that the organization is solving the right problem before significant time and budget are committed to a particular solution. 

By the end of this period, six areas should be considerably clearer: 

These areas do not always become clearer in a rigid sequence. What matters is that what the team learns leads to better decisions. 

What Should Happen Early in the Engagement? 

The early part of the engagement should establish why the organization is investing, what problem needs to be solved, who needs to be involved, and which assumptions need to be tested. 

Start With the Business Problem 

Good discovery begins with questions about the business, not a feature list. Why is the organization investing now? Where is the greatest friction? Who is affected? What has already been tried? What needs to improve for the investment to be worthwhile? 

The answers can change the direction of an engagement. A company that believes it needs to replace an application may discover that the workflows surrounding it are creating much of the problem. Another may request new functionality when the larger issue is how people and systems exchange information. 

One thing I encourage business leaders to do early is separate the solution they think they need from the problem they actually need to solve. A good software partner should help make that distinction clearer. 

Bring the Right Stakeholders Into Discovery 

Software initiatives often cross functions, and those groups may see the problem differently. Executives may focus on growth and ROI, operations on efficiency, employees on usability, and IT on security, integrations, data, and long-term support. 

Stakeholder interviews should surface those perspectives and clarify who owns the business outcome, who understands the current process, who can identify constraints, and who has authority to make key decisions. 

The objective is not agreement on every detail. It is enough alignment to make decisions when priorities compete. 

How Should Technical Assessment Influence the Roadmap? 

A technical assessment should clarify the organization’s options and tradeoffs, while the roadmap turns that understanding into priorities. 

Depending on the engagement, a technical assessment may examine existing applications, integrations, databases, infrastructure, security requirements, third-party platforms, and technical debt. The value is not simply documenting what exists. It is understanding what the current environment means for the business decision ahead. 

Evaluate the Options Before Choosing a Solution 

An aging application does not automatically need to be replaced. An assessment may reveal that much of it continues to serve the business while a smaller number of workflows, integrations, or architectural constraints are creating disproportionate friction. 

That creates choices. Leadership might modernize an existing application, improve integrations, replace a system in phases, buy and configure an existing product, simplify a business process, or build a custom application. 

A strong partner should make those tradeoffs clearer rather than assume custom development is always the answer. The right decision depends on business objectives, budget, timing, risk tolerance, internal capabilities, existing technology, and the need for flexibility or differentiation. 

Prioritize Business Value 

Once the options are understood, the roadmap should establish what deserves attention first and why. 

Trying to solve everything in the first release can increase cost, complexity, and time to value. Cutting scope too aggressively creates the opposite risk: delivering software that works but does not solve enough of the problem to matter. 

A useful roadmap connects priorities to business outcomes while identifying dependencies, risks, unresolved decisions, and assumptions that still need validation. It should provide direction without creating false certainty. 

When Should Software Development Begin? 

Development should begin when the team has enough clarity to make a responsible investment decision, not simply because a certain number of days have passed. 

That does not mean every discovery activity must be complete. Teams may prototype an idea, validate a technical approach, or begin high-priority development while other questions continue to be resolved. 

The goal is not perfect certainty. It is enough shared understanding of the business outcome, major constraints, priorities, and proposed direction to make development purposeful rather than premature. 

How Should Success Be Defined? 

Success should be defined in terms of business value, not simply whether the software was delivered. 

Project Management Institute research involving more than 5,800 project professionals, stakeholders, and knowledge workers found that only half of projects met its definition of success: delivering value that exceeds the effort and expense involved, as perceived by key stakeholders. 

For leadership teams, that raises an important question during the first 90 days: What will make this investment worthwhile? 

Connect the Project to Measurable Business Outcomes 

Success will look different depending on the initiative. It might mean reducing manual work, shortening processing time, decreasing errors, improving the customer or employee experience, supporting growth, or enabling a new revenue opportunity. 

Those outcomes may take longer than 90 days to achieve, but defining them early creates a better basis for prioritization. When a new feature request appears, the team can ask whether it contributes enough to the desired outcome to justify the additional time, cost, and complexity. 

The software is not the goal. The business improvement it enables is. 

What Should the Working Relationship Look Like? 

By the end of the first 90 days, both sides should understand how decisions, risks, progress, feedback, and changes will be handled. 

In my experience, many difficulties in technology engagements are not purely technical. They arise when expectations about responsibilities, communication, priorities, or decision-making are unclear. 

Early in the engagement, both teams should agree on: 

• How progress will be reviewed 
• Who needs to participate 
• Who has decision authority 
• How risks and blockers will be escalated 
• How feedback and changes in scope will be handled 

More communication is not automatically better communication. Executives do not need to attend every project meeting, but they need enough visibility to understand where the initiative stands, which decisions are approaching, and when their involvement is required. 

What Warning Signs Should You Watch for? 

Pay attention if requirements are accepted without meaningful questions, technology is recommended before the business problem is understood, stakeholder disagreements remain unresolved, or no one can clearly identify the decision owner. 

A roadmap built entirely around features rather than outcomes should also prompt questions. So should a partner that never discusses alternatives to custom development or communicates risks only in technical terms. 

Other warning signs include priorities changing without a clear reason, important stakeholders entering too late, or decisions repeatedly being reopened because ownership is unclear. 

These signs can indicate whether the partner is helping your organization make better business decisions or primarily waiting for instructions. 

Should You Expect Your Initial Assumptions to Change? 

A productive engagement should confirm some assumptions and challenge others as the team develops a better understanding of the business and technology environment. 

SOLTECH’s work with LG Electronics’ Commercial Air Conditioning division provides one example. LG’s Sales & Operations Planning Site (SOPS) was critical to managing commercial orders and supporting demand forecasting. The engagement initially began as a transition and support effort for the existing application.  

As SOLTECH transitioned SOPS into its development environment, the team learned the application’s existing functionality, business rules, and underlying code while conducting requirements gathering and design sessions with LG. That work ultimately grew into a redesign and rebuild of the application. It also surfaced an important technical consideration: SOPS 2.0 needed to integrate with LG Electronics’ ERP system in Korea, so changes to the application had to account for their effect on that integration.  

The resulting SOPS 2.0 was designed to better support LG’s growth, improve sales tracking and demand forecasting, enhance the user experience, and bring commercial project sales and distributor orders into one application.  

The lesson is not that every engagement should expand in scope. It is that learning the existing system, business rules, dependencies, and requirements can change what the right next step looks like. Discovery gives the organization a better basis for making that decision. 

How Should You Measure Progress During the First 90 Days? 

Progress should be measured by whether the organization can make better decisions not simply by how quickly developers begin writing code. 

Ask whether assumptions are being validated, risks are becoming clearer, stakeholders are aligned, priorities are easier to defend, and decision ownership is clear. The organization should understand its options better than it did at kickoff. 

Visible software can be progress, but so can a prototype, architecture decision, validated integration approach, or prioritized roadmap. The right measure is whether the work is reducing uncertainty and improving the quality of the decisions ahead. 

What Deliverables Should You Expect by Day 90? 

By day 90, you should have enough information to make clearer decisions about both the direction of the initiative and the partnership responsible for moving it forward. 

Depending on the engagement, deliverables may include: 

• Documented business objectives and constraints 
• Stakeholder findings 
• A current-state technology or architecture assessment 
• Prioritized requirements or opportunities 
• Technical recommendations and alternatives 
• A phased roadmap 
• Identified risks and dependencies 
• Initial success measures 
• Agreed decision-making and communication practices 

Not every engagement will produce every artifact. The more important test is whether the work makes decisions easier. 

One question I would ask at day 90 is: What do we understand differently now than we did at kickoff? 

If discovery, stakeholder conversations, and technical assessment have not sharpened or challenged any assumptions, it may be worth asking whether the process went deep enough. 

What Comes After the First 90 Days? 

What happens next should follow from what the organization has learned. 

For some teams, the next step will be development against an agreed roadmap. Others may begin with a smaller phase, address a technical dependency, modernize part of the existing environment, or decide that buying or integrating an existing platform makes more sense than building something new. 

A strong software development partner is not valuable simply because it can execute what you request. Part of its value is helping determine whether what you requested is the right investment. 

The first 90 days will not eliminate every unknown, but they should give leadership clearer choices, make uncertainty more manageable, and provide a stronger basis for deciding what to invest in next. 

FAQs 

What should happen during the first 30 days with a software development partner? 

The early weeks should establish the business problem, key stakeholders, current technology environment, major constraints, and assumptions that need validation. Technical validation or development may also begin when there is enough clarity to proceed. 

When should software development begin? 

Development should begin when the team understands enough about the business outcome, technical constraints, priorities, and proposed direction to invest responsibly. Not every discovery question needs to be resolved first. 

What should I have by the end of software discovery? 

You should have a clearer understanding of the business problem, stakeholder needs, technical constraints, solution options, major risks, priorities, success measures, and recommended next steps. 

How do I know whether the first 90 days are going well? 

Look for increasing clarity. Assumptions should be tested, risks and tradeoffs should become visible, priorities should be easier to defend, and stakeholders should understand what the initiative needs to accomplish. 

When should a business consider custom application development? 

Custom development may make sense when existing products cannot adequately support an important workflow, integration, customer experience, or source of differentiation. Compare it with buying, configuring, integrating, or modernizing existing systems before committing to a direction. 

---

Ann Mooney

Director of Business Development

Ann Mooney is the Director of Business Development at SOLTECH, and has over 30 years in Sales and Account Management in the Technology, Telecommunications, and Medical Industries. Ann’s key specialties are building long-term business relationships, results-driven sales, and account management.

Ann joined SOLTECH in 2016, she works directly with SOLTECH’s clients to help find them the best technology solutions for their business. Ann utilizes her strategic leadership and proactive problem-solving skills to continually grow SOLTECH’s business and ensure excellent customer service.

With her years of experience in the technology industry, Ann likes to share her expertise to educate her audience on the enhancement of workplace productivity and growth through software solutions in her articles. Her insights offer advice on important considerations for creating custom software, including initial steps, development costs, and timelines, as well as the advantages of collaborating with a skilled software development team.