Process, written down before we quote
SETTLED BY
MEASUREMENT
How a ZENITEX HOLDING GROUP project actually runs — from the first conversation and a written scope, through a prototype that is allowed to fail, into design, build, launch and the revision round most budgets forget. Read it before you contact us, so you can judge the method, not the pitch.
Stage one · Discovery
What problem are we actually solving
Discovery starts with a conversation and ends with a written scope. We ask who uses the current process, what tools they use today, and what would have to be true for the project to be considered successful. Then we write down what we understood — including what the project will not include.
What we put on the table
- Scope document
- What gets built, for whom, and by when. Signed off before anyone writes code.
- List of assumptions
- What we are taking on trust — third-party APIs, integrations, content readiness — stated explicitly rather than implied.
- Estimate
- A number tied to the scope we wrote, not to a similar project we once did.
This is the stage where most projects get cheaper. Finding out in week one that a feature is unnecessary costs nothing. Finding out in month three costs a rebuild.
Bench at intake
Discovery usually begins here: the current tools, the current files, the current cables. We look at what already exists before we suggest replacing any of it.
Stage two · Prototyping
Being wrong cheaply
Once the scope is settled, we build something clickable, fast. Not a polished design — a testable one. It goes in front of real users, or at least in front of the people who will have to approve the final product, and it comes back with problems.
We treat problems at this stage as the point of the exercise. A prototype that survives contact with users untouched usually means the testing was too polite.
Prototype
Also available as a standalone service, when you need a decision made before committing to a full build.
Prototype in review
We put the clickable build in front of the people who will approve it, on the screen they actually use. Notes come back as problems, not applause.
Stage three · Design & technical specification
Deciding what runs where
Only after the concept holds do we design the real interface and write the technical specification. This is where stack decisions get made: what runs on the server, what happens in the browser, what sits in the app, and how the pieces talk to each other.
Front-end work in React or Vue, back-end in Laravel or Symfony, APIs in between. Those are our defaults, not a religion. If your existing systems point elsewhere, we plan around them rather than migrating for the sake of it.
Where the decision lands
Server
Application logic, authentication, integrations with your existing systems, scheduled jobs. Laravel or Symfony are our usual default.
Browser
The interface itself, plus the interactive layer — 3D, motion, data visualisation. React or Vue are the defaults; the decision is written down, not assumed.
App
What belongs on the device, what stays online, and how the two sync when the connection drops.
Between
APIs, webhooks, and the contracts that keep every part of the system speaking the same language. Documented so a future team can pick it up.
You approve this before a single line of production code is written. Moving it later is a change request, priced as one.
Stage four · Build
The part everyone expects
Development runs in increments you can see, not in one long silence. You get access to a staging environment early and it stays current, so feedback arrives while changes are still cheap. We keep the codebase documented, because projects change hands — yours might stay with us for years, or move in-house next quarter. Both are fine, and the second one costs less if we planned for it.
-
Staging access from week one
A live deployment you can open from any browser. Not a screenshot, not an update email.
-
Feedback in the same cycle
You review what was built in the increment, not a quarterly milestone deck.
-
Documented codebase
Written so an in-house team can take over without a reverse-engineering phase.
-
Change requests priced, not absorbed
If the scope moves, you see the cost before we start the work. Nothing gets quietly billed later.
Stages five and six · Launch & iteration
LAUNCH IS A MEASUREMENT, NOT A PARTY
Launch covers more than deploying code. Domain configuration, analytics, error monitoring, and a check that the product behaves under real traffic rather than test data. We also run through the operational questions: who updates content, who handles a failed transaction, who gets alerted when something breaks.
For installations, launch means a physical install and a period of on-site testing. For mobile apps, it means the store review process — slower than clients expect, and worth planning around from the start.
After launch you learn things nobody could have told you beforehand. Which features get used, which are ignored, where users get stuck. Iteration is planned as part of the original scope, so there is budget and time left for it. A product that is never revised after launch is usually a product that quietly stops being used.
Working together
In-house teams, and the honesty we ask for
We collaborate with internal developers, designers and product managers regularly. Sometimes we take the lead, sometimes we fill a specific gap — the 3D layer, the data pipeline, the mobile build. Either way, the arrangement is written down at the start so nobody is guessing about ownership.
What we need from you
-
A decision-maker who can attend a short review at the end of each stage.
-
Access to the people who actually use the current process — not just the people who commissioned it.
-
Honesty about budgets and deadlines, including the ones that are fixed for reasons outside the project.
What can go wrong
-
Requirements change after the build starts. Normal — priced as a change request, not absorbed silently.
-
Third-party APIs turn out to be less capable than their documentation suggests.
-
A key stakeholder leaves and the approval chain moves. The scope document already lists the assumptions this affects.
None of these are unusual, which is why the discovery stage lists assumptions explicitly rather than leaving them to be discovered on the day.
Timelines in plain terms
How long things actually take
Ranges, not promises. Each one depends on how much of your existing system the project has to reach into, and how fast decisions come back to us.
-
Prototype
A clickable test build with a real user test round.
- weeks
-
Custom web application
Scope-dependent, and heavier when existing system integration is involved.
- months
-
Mobile app
Adds the store review period, which is slower than most clients expect.
- + review
-
Immersive installation
Driven by the event or exhibition date, which is often the hardest constraint in the whole project.
- event-led
If that method sounds like how you want to work, the next step is a conversation
Discovery is the cheapest stage to start with, and the easiest one to stop after. Tell us what you are trying to build and who currently struggles with the way it works — we will tell you plainly whether a prototype, a full build, or nothing at all is the right next move.
Studio
ZENITEX HOLDING GROUP
Registration 1112519823
Studio hours
Monday to Friday
9:00 AM – 6:00 PM
zenitex.digital