Guide · Ultineo SaaS
From specification to first release
This guide is for a founder or a manager whose specification is agreed and whose software is about to be built. You will learn to tell three states apart (built, tested and live), to test with your own cases and to write a change request that someone can check. It continues the guide "From an idea to a specification", where those cases are written.
Checked against the product in November 2026
Built, tested, live: three different states
- Built, in development
The work exists in the place where new work arrives. It can still change, and no user depends on it yet.
- Tested, in staging
A fixed version has passed your own cases, in a place made for checking. You know exactly what it contains.
- Live, in production
The version you checked now serves your users. A case you did not check is a case they will meet first.
- What "built" allows
You can try every journey and ask for changes. You cannot yet tell a user that it works.
- What "tested" allows
You can decide to publish, or to wait. Either way, you decide on a version that no longer moves.
- What "live" allows
You can tell your users, once you have repeated the changed task in production. The next change then goes through the same three states.
1. Start construction with the journey that is ready
An agreed specification is not a signal to build everything at once. Start with the journey whose rules are all decided: each question answered, each exception written down.
A part with an open question waits its turn. Whatever is built on an undecided rule may have to be asked for again.
Example. The workshop that repairs coffee machines for cafés has an agreed specification. Its first journey is decided: a repair asked for, assigned and confirmed. Reminders to cafés still have an open question, so they wait and the repair journey is built first.
In Ultineo. A project is opened in Ultineo SaaS after our team has reviewed your application, and your software is then designed and built with you. In the project workspace, a roadmap organizes the construction of a ready business area into phases. Open Modules and resolve the open questions of the area, then open "Create a roadmap", select the area in Module and click "Launch the roadmap". The launch form only offers work eligible for construction.
2. Answer what is waiting for you
While your software is being built, two lists matter: the work in progress and the work that waits for you. Only the second needs you: read it on fixed days.
Answer each question on the item that asks it, with the rule, an ordinary case and an exception. Do not send a new request about work that is already in progress.
Example. On Monday the manager finds one question waiting: can two repairs share a slot? Her answer: a technician has only one repair in a two-hour slot. Ordinary case: the slot is free and is assigned. Exception: it was taken a minute earlier, so the person assigning sees a message and chooses another slot.
In Ultineo. To follow the construction, click Detail on the roadmap and open its phase view: you read the sequence, the current state and the progress. Click the tasks icon in the top bar: "To do" shows the items that need a response, "In progress" the work already being processed. When an item asks a question, open "Answer the clarifications", fill in "Your answers" and click "Submit my answers".
3. Test what is built with your own cases
Built means that it exists, not that it is right. Take the test list from your specification and run each line on the real pages: the ordinary case, then the exception.
Follow each journey to its end, including the page it leads to next. Beside each line, write passed or failed and what you saw.
Example. The manager runs her six lines on the built pages. Five pass. Line four fails: a repair without a serial number should be kept and impossible to assign, yet the page lets her assign it. She writes down the page, what she did and what she saw.
In Ultineo. In the project workspace, development is the environment that receives new work. Identify the functions and pages completed by the roadmap, open the development application and test the expected user journeys and important exceptions. In the detail of a page, Information shows the expected behavior and scope: compare them with what you see. Roadmap completion describes construction progress: check the version of the environment separately before telling users that a change is live.
4. Write each change request so that it can be tested
A line that fails becomes a change request. Write four things: the page, what happens now, what should happen and one example to replay. The reader must be able to reproduce the problem and, later, to check the correction.
Ask for one result per request. Two unrelated changes in one sentence hide each other, and neither can be checked on its own.
Example. Vague: "The serial number does not work." Testable: "On the page that assigns a repair, a repair with no serial number can be assigned today. It should stay in the list, with a message naming the missing field, and not be assignable. Example: the request of the test café, sent without a serial number."
In Ultineo. A change to a page already built is prepared on the screen named "AI requests". Open the built page and copy its address, paste it into "Page name or URL", then describe what happens now, what should happen and a concrete example. The arrow marked "Add to list" prepares a row; "Send all" submits the prepared requests. Follow the request in "Changes in progress", then test the changed page in development.
5. Create a version, then check it in staging
Development keeps changing, so you cannot publish "what is in development". You publish a version: a named set of changes that no longer moves. Test it in staging, the place where a chosen version is checked before users see it.
Repeat the changed journeys there, the step that follows each one and one important exception. Note which version you checked: that is the one you will publish.
Example. The six lines now pass in development. A version is created, and the manager repeats the six lines on it in staging, then reads the confirmation as a café would, on a phone. She notes the version beside the date of her check.
In Ultineo. Open Deployment and find "Your project version". When changes are available, use "Create a version": a version groups changes for publication. Click "Deploy to staging", wait for the staging version to update, then open the staging service and test the changed journeys in the required languages. For a first release, Launch shows each step of this path: staging and production are installed only after you click "My development environment is validated".
6. Publish, then verify what is live
Publishing is a decision, not the last minute of the build. Take it when the version in staging has passed your list and when everything production needs is in place, starting with the address your users will open.
After publication, read which version is in production and repeat the changed task once, as a user would. Only then tell your users.
Example. The version is published on a Tuesday morning. The manager reads the version shown for production, asks for a repair as a café would, assigns it, reads the confirmation and cancels it. Then she writes to her first three cafés.
In Ultineo. For a first release, production waits until your domains are declared and point to the address shown on your domains page. At the review step of this first publication, click "I have reviewed my version" when you have checked the staging version. On the Production row of "Your project version", click "Deploy to production", wait for Production to show the expected version, then open the live service and repeat the changed task.
Checklist
Before you tell your users
- 1. Choose the first journey
The one whose rules and exceptions are all decided; the rest waits.
- 2. Read what waits for you
Answer each open question with a rule, an ordinary case and an exception.
- 3. Test in development
Run every line of your test list on the built pages and note what you saw.
- 4. Write testable requests
The page, what happens now, what should happen and one example, with one result per request.
- 5. Check the version in staging
The changed journeys, the next step of each and one exception, on the version you will publish.
- 6. Verify what is live
Read the version in production and repeat the task before you tell your users.
Go further
- Capabilities
- Help articles
Build your software with Ultineo SaaS
Send your application: our team reviews each one before a project is opened.
Questions
No. In Ultineo SaaS, a roadmap organizes the construction of a ready business area into phases. The agreed functions and page definitions still explain what should be built and provide the reference for reviewing the result.
It describes what happens now, what should happen and a concrete example. A useful request names an action, an exception and the visible outcome to test. Prepare unrelated changes as separate requests rather than hiding several results in one.
In Ultineo SaaS, a change request is for a specific change to an existing page; a report, sent with "Report something", records a bug, an improvement idea or a question. The guide "Running your software after launch" shows how to report a problem so that it can be reproduced.
Because the three environments have different purposes: development receives new work, staging checks a selected release and production serves users. In staging you check that release and its complete user journeys, with the surrounding links and the important exceptions.
Deployment shows the prerequisite. A version may need to be created, staged or verified, a required domain may be unverified, or a deployment may already be underway. Resolve the condition shown: repeated submission does not complete a missing prerequisite.
Because construction completion does not publish a version. Verify the result in development, create the project version, test it in staging and check the production version after deployment. Opening or restarting an environment does not by itself publish the latest changes either.