Try:

Software Discovery & Proposal

Understand the problem. Define the solution. Receive a clear proposal.

A short, paid engagement where Eforah gets to know one software, workflow or integration problem properly - and ends with a concrete written proposal for the project that would solve it: the recommended solution, the expected outcomes, the implementation direction and what it would cost.

Start with Software Discovery See what you receive

One focused problem

Not a full audit of your organisation. One workflow, system or decision that is actually worth solving.

A written proposal

Not just advice. You end up with a proposal for the actual project: recommended solution, expected outcomes, scope and an estimated investment.

No obligation to continue

Discovery has value on its own, and the proposal is yours either way. Whether you build it with us afterwards is entirely your decision.

Why Discovery exists

The first requested solution is not always the right one

Most software projects start with an assumed answer: "we need a portal", "we need automation", "we need these systems connected." Sometimes that assumption is correct. Often the real problem sits one level deeper - in how a decision gets made, which system should own which data, or what actually happens when a process breaks.

Discovery exists to test the assumption before either of us commits to building around it.

How it works

Four steps, one problem

  1. Understand the problem.The workflow, systems, bottlenecks and constraints involved, in enough detail to reason about them properly.
  2. Explore the right direction.Custom software, an integration, a smaller change, or something else entirely - decided by the problem, not assumed in advance.
  3. Define expected outcomes.What should concretely improve if the recommendation is implemented.
  4. Decide what happens next.A clear basis for a decision, whichever way it goes.

The decision at the end

  • Proceed

    The direction is clear enough to begin implementation.

  • Proceed differently

    The original idea should change before anything gets built.

  • Investigate further

    One uncertainty is important enough to validate first.

  • Don't build

    Existing software, configuration or a process change is likely the better answer.

A useful Discovery can result in a decision not to build.

Plan the right next step

What you receive

A proposal, in four parts

Discovery ends with a document you can act on - internally, with us, or with someone else. These are the four things it contains.

Problem definition

What actually needs solving - the relevant workflows, systems, bottlenecks and dependencies, described plainly.

Proposed solution

Eforah's recommended direction, and the reasoning behind it.

Expected outcomes

What should concretely change: less manual entry, fewer handovers, faster processing, better visibility - stated for your situation, not as generic promises.

Proposal for the next project

If building is justified: the proposed scope, key functionality, important dependencies, an indicative timeline and an estimated investment - a proposal you can approve or decline.

Discovery is deliberately not a full technical specification, product design or architecture document - it is enough to decide with confidence, and enough to price the work.

Discuss your project What it costs

Commercial model

Your Discovery investment becomes your continuation discount

We agree a rough estimate of the implementation before Discovery starts, based on a short conversation about the problem and systems involved. Discovery itself costs 10% of that estimate.

Software Discovery 10% of the estimated implementation
Decision Proceed, adjust, investigate further, or stop
If you continue Implementation, minus a discount equal to the Discovery fee

There is no obligation to continue after Discovery. If you don't, the fee is not returned, but nothing further is owed - and you keep the problem definition, recommendation and expected outcomes either way.

Talk about your workflow

Worth considering when

  • Existing software no longer fits how the work actually happens.
  • Systems don't communicate, and information gets copied by hand.
  • Excel or email have quietly become part of a critical process.
  • A software idea exists, but the scope is genuinely unclear.
  • An automation opportunity needs validating before you invest in it.
  • An internal application or portal may be the answer - or may not be.

Probably not necessary when

  • The implementation is already sufficiently clear.
  • Existing software already solves the problem with configuration.
  • A small, well-understood integration would resolve it directly.
  • The process itself should change before any software does.
  • The value at stake doesn't justify custom development.

The same judgment, on real projects

Eforah's recommendations vary by problem

Software Discovery is a new way of starting a project, but the judgment behind it is not. These are real Eforah projects, and the recommended direction was different each time.

Finrust

The right answer was custom software: a financial planning application built around how advisors actually work.

Read the Finrust project

Kifid

The right answer was an integration: a dedicated API into existing case-management systems, not a new platform.

Read the Kifid project

Questions we hear

Before you commit to Discovery

How much does Software Discovery cost?

10% of the currently estimated implementation for the problem you bring us. We agree that estimate with you, based on a short conversation, before Discovery starts.

What is the initial estimate based on, if Discovery hasn't happened yet?

A short conversation about the problem, the systems involved and roughly what implementing a fix would take - enough to price Discovery fairly, without needing the deeper analysis Discovery itself produces.

What happens if we continue with Eforah afterwards?

The full Discovery fee becomes a continuation discount on the implementation. You do not pay for Discovery twice.

What happens if we don't continue?

Nothing further is owed. The proposal is yours - problem definition, recommendation, expected outcomes and implementation direction - and you can act on it internally or take it to someone else.

Does Discovery always lead to custom software?

No. A Discovery can just as easily recommend an integration, a process change, configuring something you already own, or no build at all. Recommending work we would not get to build is a normal outcome, not an exception.

Is Discovery a complete technical specification?

No. It is enough to make a confident decision and estimate implementation - not a full architecture document or product design. That level of detail comes later, once you decide to proceed.

Is this just a quotation?

No. A quotation prices work you have already specified. Discovery is the paid work of establishing what should be built in the first place - and the proposal at the end is the result of that analysis, not a sales document produced before it.

Related

Have a software problem worth solving?

Start by finding out what should actually be built

Bring the problem, not a finished specification. We'll tell you honestly what we find - including if the answer is "not much."

Discuss your project
Let us contact you