Guide · Ultineo SaaS
Running your software after launch
This guide is for a founder or a manager whose custom software is now live. You will know what to keep in view once construction is finished: access, addresses, environments, running costs, problem reports and change requests. It closes the series opened by the guides "From an idea to a specification" and "From specification to first release".
Checked against the product in November 2026
Six things to keep in view
- Who has access
Every person who can sign in to the administration, in each environment of your software. A list nobody reviews keeps the people who have left.
- Which addresses answer
Every address your users open, and the person who controls its domain. An address works until the day a record changes or a name is not renewed.
- Which environments run
Custom software usually exists in several environments: one to build, one to test, one that serves users. Know which are running today, and why.
- What it costs to run
A subscription, hosting and test time are not measured the same way. Each amount should lead you back to a record you can open.
- How a problem is reported
A problem is something that worked, or should work, and does not. It is reported so that another person can reproduce it.
- How a change is requested
A change is something new you want, however small. It is written, tested and published like the first version.
1. List who can sign in, environment by environment
For each environment, list who can sign in to the administration of your software, with what role and since when. An account in the test environment is not an account in the live one.
Withdraw an access on the day the person leaves. Then ask in writing: who, outside this list, can reach your data to maintain the software, and how is that access granted and withdrawn?
Example. Three months after its first release, the workshop that repairs coffee machines for cafés has four names on its list. One is a technician who left last month: the manager withdraws his access. Her deputy has an account in the test environment and none in the live one.
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, Access shows the accounts that sign in to the back office of your project, and each environment has its own accounts: choose Development, Staging or Production, then read the account name, Status and "Last login". To withdraw an ordinary access, click Delete, check Name and Email, then click "Remove access" under "Confirm removal".
2. Check every address your users open
List the addresses your software answers on: the application, its administration, the website, the help pages. Open each one as a user would.
Then look behind the address. Note who holds the domain, who can change its records and when it must be renewed.
Example. The workshop has three addresses: the one where cafés ask for a repair, the help pages and the website. All three open. The domain, though, still sits in the personal account of whoever registered it. The manager has it moved to an account of the workshop.
In Ultineo. In the project workspace, Service lists the addresses of an installation: select Development, Staging or Production. A domain is declared with "Add a new domain", then verified: you add the ownership TXT record at your DNS provider and click Verify. Each service address then has its own record, which you check with "Check the DNS record". These checks use different DNS records.
3. Know which environments are running, and why
The three environments are usually called development, staging and production. After launch, the first two are only useful while a change is built or tested. Decide who pauses them and who starts them again.
For production, put two questions in writing to whoever hosts your software: what happens when it stops answering, and what is saved, how often and how it is restored? Keep the answers with your contract.
Example. Nothing has changed in the workshop's software for six weeks, yet both test environments are running. The manager has them paused and notes that they must be started before the next change.
In Ultineo. In Infrastructure, choose the development, staging or production view and read the current state. To pause a test environment, select development or staging, open the Suspend action, check Environment on the confirmation screen and confirm with Suspend; a paused environment is resumed by confirming with Start. From the project workspace, only development and staging can be suspended, and they can also be suspended automatically when unused.
4. Trace every amount back to its record
The cost of running software is rarely one line. Separate what is fixed, such as a subscription, from what is measured, such as hosting or test time, and ask where each measure is read.
Then take one period and trace every amount back to a record: an offer, an environment and its dates, an invoice. An amount you cannot trace is a question to ask, not a line to approve.
Example. The manager reads her last quarter: the subscription for the application, the hosting of production and the running time of the test environments. One period falls outside the week a change was tested: staging was left running.
In Ultineo. The project workspace shows two separate activity measures, neither of which replaces an invoice: tokens, whose totals are on the Dashboard, and the running periods of each environment. For hosting, open Billing in Infrastructure, read Summary for each environment, then "Current billing periods": Environment, Period, Duration and Amount. Production uses the displayed monthly subscription; development and staging use recorded hourly periods. Invoices shows the Number, Description, Date, Status and Amount of each recorded invoice, and "Your offer" the "Monthly subscription" of the application.
5. Report a problem so that it can be reproduced
Report a problem as a sequence another person can repeat: the page, the environment, the steps, what you saw and what you expected.
Keep every later message with the first report. Ask also, before the first serious problem, within what time a report is read and what to do if production cannot be used.
Example. A café says that its confirmation shows the wrong day. Vague: "Dates are broken." Reproducible: "In production, a café asks for a repair on a Friday evening. The confirmation shows Saturday. Expected: Monday, the next day the workshop is open. Example: the request of the test café."
In Ultineo. In the project workspace, open the feedback list and click "Report something". Choose the Type (a bug, an improvement idea or a question), select the Environment, enter a Title, explain the issue in "What's wrong or what would you like?" and click Send. To follow the report, read Status, click View and consult Details and Conversation; "Add a message" adds context to the existing conversation.
6. Treat every change as a small first version
A change is not a problem: nothing is broken, you want something new. Decide first what it is: a change to an existing page, or a new need with its own rules.
Write the first so that it can be tested and the second as a requirement, with its ordinary case and its exception: the two earlier guides of this series show how.
Example. Two requests reach the manager. A café wants the phone number of the technician on the confirmation: a change to an existing page. The workshop wants to follow its stock of spare parts, on the "later" list since the specification: a new need, written as a requirement before anything is built.
In Ultineo. In the project workspace, a specific change to an existing page is prepared on the screen named "AI requests", and a new business requirement is described with "Request an evolution", in the evolution view of its business area. The end of construction 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.
Checklist
The day after launch
- 1. List who can sign in
One line per person and per environment, reviewed each time someone leaves.
- 2. Open every address
Open each one as a user would, and note who can change its domain records.
- 3. Pause what is not in use
Test environments run while a change is tested; note who starts them again.
- 4. Trace every amount
Subscription, hosting or test time: each line leads to a record and a period.
- 5. Separate problems from changes
Report a problem so that it can be reproduced; write a change so that it can be tested.
- 6. Ask the open questions
Availability, response time, backups and security: in writing, with the answers kept.
Go further
- Help articles
Follow your software after launch with Ultineo SaaS
Send your application: our team reviews each one before a project is opened.
Questions
Because administration accounts belong to an environment. In Ultineo SaaS, creating an account in development does not automatically create its production counterpart: check whether the account exists in the access list of the environment concerned.
No. In Ultineo SaaS, the ownership check proves control of the name, and a service address then directs users to the application, the website or the documentation. The two use different DNS records and are completed separately: the ownership TXT record is not the address target.
No. Availability and publication are separate. When staging starts, it can serve the version that was already published there: read the environment version in Deployment after the start completes.
No, they are separate parts of the project cost. In Ultineo SaaS, read the application offer, the infrastructure billing and the invoices. For hosting, identify the subscription of production and the recorded running periods of development and staging.
A follow-up in the same report, not a new report. In Ultineo SaaS, repeat the original steps in the environment and the version that contain the correction, then open the report detail and use "Add a message": identify the version tested and the exact step that still differs.
Not necessarily. In Ultineo SaaS, the allowance of an offer counts business areas, not pages: one area can contain several functions and pages. Review whether the need extends an existing area or introduces another business responsibility, then compare "Modules included", "Modules used" and "Modules remaining" in "Your offer".