Before you hire a software developer, explain your problem—not your solution

Start with the problem behind the feature list

Imagine a property manager starting a conversation with Renatus. This is an illustrative example:

That tells me what the manager has in mind. Now compare it with this:

Now we have a specific job to investigate. Where are requests recorded? Who owns the next step? How does the manager know a repair is complete? What happens when a contractor doesn’t respond?

A tenant dashboard might help. A shared request tracker might be enough. A payment system may have no bearing on the maintenance problem at all. Understanding the work lets us evaluate each idea against the outcome it is supposed to support.

Walk me through the last time you did it

One of the most useful questions for a discovery conversation is:

Walk me through the last time you had to do this task, from beginning to end.

Choose an actual request, order, appointment, or shift. Describe what you did at each step, including the things that felt too ordinary to mention.

• What started it? A text, an email, a form submission, or something you noticed?
• Where did the information go? A spreadsheet, a notebook, another application, or your memory?
• Who acted next? What did they need to know, and how did you pass it along?
• Where did it stall? Were you waiting for approval, chasing a reply, or entering the same information again?
• How did you know it was finished? Who confirmed the result, and where was that recorded?

The property manager might discover that “I follow up” actually means searching several text threads each morning and trying to remember who promised to call back. That detail changes what we need to solve.

Then walk through an exception: an urgent repair, a duplicate request, or a contractor who cancels. If the process only works when everything goes right, we haven’t understood enough of it yet.

Your solution ideas belong in the conversation

You know your business. You may have already tried several tools, tested a workaround, or identified a feature your team genuinely needs. Bring that experience.

The useful distinction is between an idea to explore and a requirement that cannot change. “Maybe tenants could submit requests through a portal” leaves room to discuss adoption and alternatives. “Contractors must only see the jobs assigned to them” identifies an access requirement we need to respect.

Explain why an idea matters, what you have tried, and what cannot change. If your team needs to keep using a particular system, or your customers struggle with additional logins, that belongs in the discussion early.

A developer should ask questions, explain tradeoffs, and help you evaluate options. You should be able to understand why a proposed feature is worth building.

Describe what a better day would look like

“Save time” is a reasonable goal. Make it specific enough to check. For the property manager, useful outcomes might be:

• Every open request has a named person responsible for the next action.
• The manager can see which repairs are waiting on a contractor without searching text messages.
• A request stays open until someone confirms that the work is complete.

Share how often the problem happens, roughly how much time it takes, and what a missed step costs the business. Estimates are fine if you label them as estimates. This helps us decide which improvement deserves attention first.

You can also name what already works well. The goal is to improve the process without accidentally discarding the parts your team relies on.

Discovery turns that conversation into a plan

A feature list describes things you could build. Discovery connects those things to the people, decisions, information, and exceptions that make the business run.

At Renatus, a paid discovery and architecture engagement can define the workflow, users, business rules, access boundaries, integration approach, and a focused first release. It also establishes what is excluded, how the result will be checked, and the proposed milestones and estimate.

That planning may point toward a custom application. It may also reveal that an existing product, a small integration, or a clearer handoff is the sensible next step. The recommendation should follow from the problem.

An initial conversation is free. Paid discovery begins after we agree on its scope and fee, and implementation is priced separately. See Renatus discovery and architecture pricing for the engagement details.

Once the problem is clear, the next step is making the rules explicit. The companion guide, How to explain your business process to a software developer, shows how real examples and exceptions become requirements you can review together.

Bring a starting point, not a finished specification

Before the conversation, jot down these six things:

• The problem: what keeps going wrong or taking too much effort.
• The current process: how you handled one recent example, step by step.
• The evidence: a sample spreadsheet, form, or request with private details removed.
• The exceptions: what happens when the normal process breaks down.
• The desired outcome: what would make the work measurably easier or more dependable.
• Your ideas and constraints: possible solutions, previous attempts, budget, timing, and systems you need to keep.

You don’t need every answer. “I’m not sure how we handle that” is useful information, too. Your developer’s job includes helping you uncover the missing pieces.