Skip to content
ORSEN
tren

(01)PROCESS

Seven steps. You always know what happens in each.

We don't keep the process mysterious. You always know which stage you're in, what comes next and what's expected from you.

  1. Discovery

    Understanding the need and the current system.

    • We map how the work runs in practice — not the process document, but what people actually do.
    • Existing systems, data and integration requirements are listed.
    • By the end of this stage, the problem to be solved should fit in one sentence.
  2. Strategy

    Setting the right product scope and technical architecture.

    • We decide what will not be in version one — the most expensive mistake is packing everything into the first release.
    • Technology is chosen on requirement, team and maintenance cost. No favourite stack.
    • You get a phased schedule and budget.
  3. Design

    Building the user flows and the interface.

    • Sequence first: what the user sees at each step. How the screen looks comes after that.
    • You try a clickable prototype; wrong decisions get caught before they reach code.
    • Design is delivered as a system to build on, not a one-off file.
  4. Development

    Building it modular and ready to scale.

    • We start with the parts that cost most to change later: authentication, permissions and the data model.
    • Two-week cycles; you see something working at the end of each one.
    • Every change goes through automated tests.
  5. Testing

    Performance, security, accessibility and functional testing.

    • Behaviour under real volume, permission gaps and data integrity all get tested.
    • Responsiveness, keyboard use and screen reader support are measured.
    • The performance budget is verified before launch.
  6. Launch

    Going live, measuring and handing over.

    • Staged rollout with a rollback path kept open.
    • Error tracking and analytics are set up; old URLs are redirected where they exist.
    • We walk your team through it and hand over documentation and ownership of the code.
  7. Continuous improvement

    Maintenance, optimisation and new features.

    • Error and performance monitoring continues.
    • Work is prioritised on real usage data rather than assumptions.
    • If you want to move it in-house, we plan an orderly transition.

Common questions

Can we change direction mid-project?

Yes — that's the point of shipping in slices. Because you see something working every two weeks, a wrong direction gets caught early. If a scope change affects the schedule or budget, we put that in writing at the moment it comes up.

What's expected from us?

Time from someone who knows the business during discovery, and roughly an hour every two weeks to review progress. Beyond that, quick answers where a decision is needed — pending decisions are what costs the most time.

Fixed price or time and materials?

Where scope is clear, we quote a fixed price. Where scope will only become clear during discovery, we price the discovery stage alone and set the rest against what it turns up. Quoting a fixed price for unclear scope costs both sides.

If you have a question, let us start there.

Tell us what you are trying to do. On the first call we will tell you whether we are the right fit, roughly how long it takes and how we would approach it. No sales pitch.

orsenyazilim@gmail.com