Skip to content
Iterna

You don’t need to know how to build software. That’s our job.

Most software projects fail before anyone writes code, because nobody properly worked out what should be built. Our process exists to turn a business problem into clear decisions before development starts.

  1. 01

    Tell us what’s happening.

    No technical brief required. Explain the problem, idea or workflow the same way you’d explain it to a colleague.

  2. 02

    Understand before prescribing.

    We ask about the users, the business, the workflow, the systems you already have, your constraints and the outcome you want. We don’t assume the answer is custom software before we understand the problem.

  3. 03

    Define the first useful version.

    We separate what’s essential from what can wait. That produces a clearer scope, a smaller build, and a faster answer to whether it works.

  4. 04

    Design the experience.

    We map how people move through the product and design the interface around what they’re trying to accomplish. Changing your mind here costs almost nothing. Changing it later costs a great deal.

  5. 05

    Build in visible stages.

    The software takes shape progressively, so decisions can be reviewed while they’re still cheap to change. You’re not waiting until the end to see it.

  6. 06

    Test the real workflow.

    Testing isn’t only whether the buttons work. We check whether the product makes sense to someone trying to do the actual job it was built for.

  7. 07

    Launch.

    Once the agreed scope is ready, the product is prepared for real use with real data.

  8. 08

    Learn and improve.

    Real users reveal what planning can’t. Improvements get prioritised from what actually happens, not from a feature list written before launch.

Build less. Solve more.

Every extra feature adds cost, complexity and something else that can break. Good product work is mostly knowing what not to build. We start with the smallest thing that properly solves the problem, then expand when there’s a reason to.

How we scope a first version

What happens before you commit?

The first conversation is about understanding the problem. You shouldn’t have to commit to a large software project just to find out whether it makes sense to build one — and if it doesn’t, we’d rather tell you early than take the work.

See this process on a real project

Tell us what you’re working on

The first conversation is about understanding the problem, not committing to a project. Describe what’s happening and we’ll tell you what’s worth building.

Tell us your problem