Domínio Visual is not a startup. It is a signage company — block letters, façades, panels, interior wayfinding — working for clients who need the job installed on a specific date, not during a hypothetical sprint.
This is about what happens when a real service business decides to stop running work orders through Excel sheets, notebooks and WhatsApp threads, and starts operating through a bespoke digital platform. What you gain, what you lose, and what almost always goes wrong on the first attempt.
Executive summary
A service business has three chronic operational problems: the real status of every job is spread across several heads, client history lives inside conversations, and invoicing depends on whoever remembers what was done. Off-the-shelf software fixes none of this because the vocabulary is wrong. The answer is a platform built around the actual flow of the company, with states that mirror the physical phases of the work and an interface anyone on the team can use without training.
For Domínio Visual, this meant modelling ten states that run from "site visit" to "invoicing", a MariaDB database designed around work orders, and a frontend that assumes the user is in the middle of a job, not staring at a metrics dashboard.
The business problem
A signage company works project by project. Every work order goes through several physical stages: someone visits the site to measure, someone draws the layout, the layout goes to the client for approval, the material is printed or cut, the metal structure is fabricated if it is outdoors, the piece is assembled in the workshop, installation is scheduled, delivered, and only then invoiced.
Each of these stages involves different people. The sales person who did the site visit is not the designer who draws the layout. The designer is not the operator of the cutting machine. Whoever installs on site is rarely whoever was at the workshop. And the client rings up to ask "so, how is my job going?" to any of them.
Without a platform, the answer depends on who picks up the phone. Each person holds one piece of the puzzle. The consolidated view does not exist anywhere — it is distributed.
Why this matters more than it seems
There are three hidden costs in this model, and all of them eat margin without ever showing up on the P&L.
First, the coordination cost. Every job generates ten to twenty micro-conversations on WhatsApp just to confirm status. Multiply that by thirty or forty jobs in progress and you have several hours a day of skilled staff doing the work of a system.
Second, the rework cost. Without centralised history, work is often redone because the approved version of the layout is buried in an email from three weeks ago, or because the measurement was pencilled in and no one can read it.
Third — and this one hurts the most — the cost of missed invoicing. Jobs that got installed but were never billed because they fell off the radar. Change orders agreed verbally that never made it into the final quote. An Aberdeen Group study a few years back suggested that companies without structured digital processes lose between 1% and 3% of annual revenue in work that is never invoiced or never collected. It is not a number that appears anywhere — it quietly vanishes.
What "digital platform" means for a business like this
It is not a CRM. It is not an ERP. It is not Trello with custom columns. It is all of those things at once, but with vocabulary that matches exactly what the company does.
The difference is subtle but decisive. If the software calls a work order a "deal", an "opportunity" or a "task", the team will never use it consistently. If it calls it an "OS" and uses the states the team already uses mentally — site visit, layout, approval, printing, cutting, metalwork, production, assembly, dispatch, invoicing — adoption is immediate.
This is the central argument for bespoke software in a service business: it is not about features. It is about language.
The technical decisions that matter for the business
Every technical choice here was made with operational impact in mind, not with what is interesting for the developer.
The database is relational MariaDB, not a fashionable NoSQL store. Because a work order has rigid relationships with client, items, history and invoicing, and when an accountant needs to run a query at year end, SQL is a language many people can read.
Authentication uses bcrypt for new users but keeps compatibility with legacy MD5. It is not elegant. It is pragmatic: existing users do not need to reset their password on migration day, which is the difference between "everyone uses it" and "half the team gave up".
The frontend is a fast SPA served by Nginx, with a Fastify API in Node.js behind it. It could have been a classic Rails app with server-side rendering. The SPA choice comes from a concrete requirement: the person out on an installation needs to update status from their phone, often on a weak mobile connection. An SPA with local state and asynchronous sync works better there than a system that demands a full round-trip on every click.
That is the only reason the decision makes sense. If everyone worked from an office with fibre, a traditional app would have been cheaper to build and maintain.
Modelling the real flow: the problem of states
The most common mistake when digitising a business like this is to translate the real flow into a simplified model of three or four states: pending, in progress, done. It looks clean in a diagram and is useless in the field.
Domínio Visual runs on ten distinct states. Each one maps to a physical phase of the work and to a specific team or person responsible for it:
- Closed (0) — final state, after invoicing
- Visit (1) — sales person goes on site to measure
- Layout (2) — designer creates the visual proposal
- Printing (3) — vinyl or printed material
- Cutting (4) — letter or rigid material cutting
- Metalwork (5) — metal structure where applicable
- Production (6) — workshop assembly
- Installation (7) — on-site installation at the client
- Dispatch (8) — delivery logistics
- Invoicing (9) — invoice issuing
- Layout approval (10) — client validates before printing
This level of granularity is not over-engineering. Each state corresponds to a specific person who needs to know "which jobs are on my plate right now". Collapsing two states into one means that person starts seeing jobs that are not for them. Adoption drops immediately.
History: the invisible feature that solves more problems than any other
Every work order has a history table attached to it. Every state change, every note, every attachment is recorded with a timestamp and the user who made the change.
This is the feature nobody asks for during requirements gathering and becomes the most-used one six months later. Because it solves three operational problems that did not seem to have a technical solution:
When a client rings up to complain, anyone on the team can reconstruct the exact timeline of the job without relying on the memory of whoever was involved.
When there is an internal argument about "who said what to whom", there is a neutral record that settles it in seconds.
When a new team member joins, they can understand the context of older jobs without having to ask five different people.
The rule of thumb is this: if something could generate a question like "so, when exactly did…" or "who was it that…" three months later, it has to be in the history. Always.
What almost always goes wrong on the first attempt
It is worth being specific about the mistakes that show up in almost every project of this kind, so anyone considering it knows what to avoid.
Mistake one: starting with the invoicing module. It is intuitive — invoicing is where the money comes in, so it feels like the priority. It is wrong. If the rest of the system is not being used, invoicing continues to happen outside the system as before. Start with the operational state of work orders; invoicing will follow naturally.
Mistake two: asking everyone on the team for input before building. Each person wants to optimise the software for their own slice of the flow, which produces a Frankenstein of contradictory features. Pick one or two experienced people who see the business end to end and ignore the rest until there is a working version to react to.
Mistake three: not migrating historical data. A new system without the last two years of jobs is an empty system. The team keeps going back to the old one to check the past. Data migration is dull, technical and unglamorous, but without it adoption is always partial.
Mistake four: dashboards before flow. Charts get looked at once a week by management. The daily flow is used by everyone. A platform without dashboards but with a working flow is useful from day one. The opposite is not.
Good practice that applies to any service business
Domínio Visual does signage, but the pattern applies to any company that sells projects: creative agencies, construction, architecture, workshops, print shops, AV integrators, event companies.
- Model the states the team already uses mentally, not the ones that look clean on a diagram
- The history of every job is mandatory, not optional
- Hybrid authentication during migration — do not force everyone to reset their password on day one
- Relational database for operational data; if you need complex analysis later, export
- Interface designed for mobile use on a poor connection, not for an office monitor
- Invoicing comes after the operational flow is consolidated, never before
- One internal owner with decision-making authority, not a committee
On choosing between off-the-shelf and bespoke software
The right question is not "does bespoke cost more?". It does. The question is: how much is it worth to have the team use the system every day and not abandon it after three months?
Off-the-shelf software — a Monday, an Asana, a HubSpot bent into shape with custom fields — is cheaper to buy. It is also systematically more expensive to maintain, because it forces the team to mentally translate the software's vocabulary into the business's vocabulary. That translation fails exactly when the system is most needed: under pressure, with an angry client and a tight deadline.
Bespoke software with its own vocabulary removes the translation. The upfront cost is higher. The total cost of ownership over five years is almost always lower. And the value of having structured operational data in your own schema — one you can query, export, analyse without depending on limited third-party exports — is hard to overstate.
This is not a universal rule. A small team just starting out should use Notion or a spreadsheet until it hurts. When it starts to hurt, that is the signal to build.
Security and continuity
A platform that manages work orders, client data and invoicing history quickly becomes business-critical. That forces three disciplines that service companies have traditionally underestimated.
Backups. Not weekly. Daily at a minimum, ideally hourly incrementals. Tested. A backup that has never been tested is a hope, not a guarantee. Do a full restore in a separate environment at least twice a year.
Mandatory HTTPS with certificates renewed automatically via Let's Encrypt. This has been standard since 2016 and even today you still find companies with a broken padlock in the browser. There is no technical justification in 2026 for serving a business management application over HTTP.
Role-based access control. Not everyone needs to see everything. If the sales person does not need to see margins, they do not see them. If the installer only needs the address and the time slot, that is all that shows up. Least privilege, as OWASP has described for decades, is not paranoia — it is basic hygiene.
GDPR: what changes when you own the software
Service companies in Portugal handle personal data from clients: names, addresses, contacts, often tax numbers. GDPR Article 6 requires a clear legal basis for processing this data, and Article 32 requires appropriate technical measures.
Owning the software gives concrete advantages here: you can implement proper data retention, pseudonymisation where it makes sense, right-to-erasure without depending on support tickets to external vendors, and auditable who-did-what logs. Off-the-shelf SaaS gives all of this in theory; in practice, each of these capabilities depends on the contracted plan and the response from support.
Real cost: what no one puts in the proposal
A project like this, done properly, has four cost components that most proposals underestimate.
Initial development is the visible part — building the application, the design, the tests, going into production. Typically between 40% and 60% of the total cost in the first year.
Data migration is always underestimated. Extracting data from Excels, scanned paper sheets, old systems, and turning it into something consistent to import, takes longer than any reasonable estimate suggests. Reserve at least 15% of the budget.
Training and hand-holding during the first weeks. The first two weeks after launch decide whether adoption takes hold or not. Having someone available to answer questions, fix small bugs quickly and tweak UX details is what separates "the team adopted it" from "the team went back to WhatsApp".
Ongoing maintenance. Server, backups, security updates, small monthly improvements. A predictable monthly figure that many companies like to pretend does not exist until the system breaks.
Signs it is time to do this
A few concrete signs, from the mildest to the most severe, that a service business is reaching the limit of manual management:
- You get calls from clients asking about jobs and need to check with three people before answering
- The person who runs the main Excel went on holiday and the business slowed down
- You find jobs completed weeks ago that were never invoiced
- Internal arguments end with "I thought you were going to handle that"
- New hires take weeks to figure out where anything is
- When you grow 20%, coordination gets exponentially worse instead of scaling linearly
If you recognise two or three of these signs, it is probably time. If you recognise four or more, it was time two years ago.
Key takeaways
A service business does not need impressive technology. It needs a system that uses the right vocabulary, captures the real state of the work, keeps an auditable history and works on the phone of whoever is in the field.
The choice between off-the-shelf and bespoke is a decision about total cost of ownership and about the real probability of adoption by the team. Off-the-shelf is cheaper to start; bespoke is cheaper to maintain and to use. For critical operations, bespoke almost always wins over three to five years.
Migration is a change management question more than an engineering one. The software being ready is a necessary condition but not a sufficient one. Without an internal owner with authority and without serious migration of historical data, even the best system ends up half-adopted.
The next piece looks at the opposite case: when it makes sense to keep everything on spreadsheets and resist the temptation to digitise too early. Not every company is ready, and sometimes building a system is just a way of putting off operational decisions that need to be made first.