Domínio Visual isn't a startup. It's a visual signage company — block letters, facades, panels, interior wayfinding — serving clients who need the work installed on a specific date, not during a hypothetical sprint.
This piece is about what happens when a real services business decides to stop managing job orders through Excel sheets, notebooks, and WhatsApp threads, and starts operating through a custom-built digital platform. What you gain, what you lose, and what almost always goes wrong on the first attempt.
Executive summary
A services business has three chronic operational problems: the real status of each job is spread across several heads, client history lives inside conversations, and invoicing depends on who remembers what got done. Off-the-shelf software solves none of this because the vocabulary is wrong. The answer is a platform designed around the company's real workflow, with states that match the physical phases of the work and an interface anyone on the team can use without training.
At Domínio Visual, that meant modeling ten states running from "site visit" to "invoicing," a MariaDB database designed around job orders, and a frontend that assumes the user is mid-install on a job rather than staring at a metrics dashboard.
The business problem
A signage company works project by project. Each job order passes through several physical stages: someone goes on site to measure, someone draws the layout, the layout goes to the client for approval, material is printed or cut, metalwork is fabricated if it's an exterior piece, assembly happens at the workshop, installation is scheduled, the work is delivered, and only then is the invoice issued.
Each of these stages involves different people. The sales rep who did the site visit isn't the designer drawing the layout. The designer isn't the one running the cutter. Whoever installs on site is rarely the same person who was at the workshop. And the client calls to ask "so how's my job going?" to any of them.
Without a platform, the answer to that question depends on who picks up the phone. Each person holds one piece of the puzzle. The consolidated view doesn't exist anywhere — it's scattered.
Why this matters more than it looks
There are three hidden costs in this model, and all of them eat into margin without showing up on the P&L.
First, the cost of coordination. Each job generates ten to twenty micro-conversations on WhatsApp just to confirm status. Multiply that by thirty or forty active jobs and you've got several hours a day of skilled people doing the work of a system.
Second, the cost of rework. Without centralized history, work gets redone because the approved version of the layout is buried in an email from three weeks ago, or the measurement was scribbled in pencil and no one can read it.
Third — and this is the most expensive — the cost of missed invoicing. Jobs that got installed but 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 lost between 1% and 3% of annual revenue to uninvoiced or uncollected work. That number doesn't show up on any statement — it quietly disappears.
What "digital platform" means for a business like this
It isn't a CRM. It isn't an ERP. It isn't a Trello board with custom states. It's all of those at once, but with a vocabulary that matches exactly what the company actually does.
The difference is subtle but decisive. If the software calls a job order a "deal," an "opportunity," or a "task," the team will never use it consistently. If it calls it a "JO" and uses the states the team already thinks in — site visit, layout, approval, print, cut, metalwork, production, assembly, dispatch, invoicing — adoption is immediate.
That's the core argument for custom software in services businesses: it isn't about features. It's about language.
The technical decisions that matter to the business
Every technical choice here was made with operational impact in mind, not with what's interesting for the developer.
The database is relational MariaDB, not some fashionable NoSQL store. Because a job order has rigid relationships with client, line items, history, and invoicing, and when an accountant needs to run a year-end query, SQL is a language plenty of people can read.
Authentication uses bcrypt for new users but keeps backward compatibility with legacy MD5. It isn't elegant. It's pragmatic: existing users don't have 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 through Nginx, with a Fastify Node.js API behind it. It could have been a classic Rails app with server-side rendering. The SPA choice comes from a concrete requirement: field installers need to update status from their phone, often on a weak data connection. A SPA with local state and async sync works better in that context than a system demanding a full round trip on every click.
That's the only reason the decision makes sense. If everyone worked from a fiber-connected office, a traditional app would have been cheaper to build and maintain.
Modeling the real workflow: the state problem
The most common mistake when digitizing this kind of business is translating the real workflow into a simplified model of three or four states: pending, in progress, done. It looks clean on a diagram and it's useless on the ground.
Domínio Visual operates with ten distinct states. Each one maps to a physical phase of the work and to a specific team or person in charge:
- Closed (0) — final state, after invoicing
- Site visit (1) — sales rep goes on site to measure
- Layout (2) — designer creates the visual proposal
- Print (3) — vinyl or printed material
- Cut (4) — letter cutting or rigid material
- Metalwork (5) — metal structure if applicable
- Production (6) — workshop assembly
- Install (7) — on-site installation
- Dispatch (8) — delivery logistics
- Invoicing (9) — invoice issued
- Layout approval (10) — client sign-off before printing
This level of granularity isn't over-engineering. Each state corresponds to a specific person who needs to know "what jobs are on my plate right now." Collapsing two states into one means that person starts seeing jobs that aren't theirs. Adoption drops immediately.
History: the invisible feature that solves more problems than any other
Every job order has an associated history table. Every state change, every note, every attachment is logged with timestamp and the user who made the change.
This is the feature nobody asks for during discovery and becomes the most-used one six months later. Because it solves three operational problems that didn't seem to have a technical solution:
When a client calls to complain, anyone can reconstruct the exact timeline of the work without depending on the memory of whoever was involved.
When there's an internal argument about "who said what to whom," there's a neutral record that settles it in seconds.
When a new team member joins, they can get context on old jobs without having to ask five different people.
The rule of thumb: if something can trigger a "so when did…" or "who was it that…" question three months later, it has to be in the history. Always.
What almost always goes wrong on the first attempt
It's 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 feels intuitive — invoicing is where the money comes in, so it seems like the priority. It's wrong. If the rest of the system isn't being used, invoicing keeps happening outside the system the way it always did. Start with the operational state of job orders; invoicing follows naturally.
Mistake two: asking the whole team for input before building. Each person wants to optimize the software for their slice of the workflow, 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's 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 look up the past. Data migration is tedious, technical, and unglamorous, but without it adoption is always partial.
Mistake four: dashboards before workflow. Charts get looked at once a week by management. The daily workflow is used by everyone. A platform with no dashboards but a functional workflow is useful from day one. The reverse isn't.
Practices that apply to any services 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 thinks in, not the ones that look clean on a diagram
- History on every job is mandatory, not optional
- Hybrid authentication during migration — don't force everyone to reset their password on day one
- Relational database for operational data; if you need complex analytics later, export it
- Interface designed for mobile use on a bad connection, not for an office monitor
- Invoicing comes after the operational workflow is consolidated, never before
- One internal owner with decision-making authority on the project, not a committee
On choosing between off-the-shelf and custom
The right question isn't "does custom cost more?" It does. The question is: how much is it worth that the team uses the system every day and doesn't 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's 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 breaks exactly when the system was most needed: under pressure, with an angry client, on a tight deadline.
Custom software with its own vocabulary removes that translation layer. The upfront cost is higher. Total cost of ownership over five years is almost always lower. And the value of having structured operational data in your own schema — queryable, exportable, analyzable without relying on third-party export limits — is hard to overstate.
This isn't a universal rule. A small team just getting started should use Notion or a spreadsheet until it hurts. When it starts hurting, that's the signal to build.
Security and continuity
A platform managing job orders, client data, and invoicing history quickly becomes business-critical. That calls for three disciplines services companies traditionally underestimate.
Backups. Not weekly. Daily at a minimum, ideally hourly incrementals. Tested. An untested backup is a hope, not a guarantee. Run a full restore to a separate environment at least twice a year.
HTTPS mandatory, with certificates auto-renewed through Let's Encrypt. This has been standard since 2016 and companies still show up with a broken padlock in the browser. There's 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 rep doesn't need to see margins, they don't. If the installer only needs the address and the time slot, that's all they see. The principle of least privilege, as OWASP has been describing for decades, isn't paranoia — it's basic hygiene.
GDPR: what changes when it's your own software
Services companies in Portugal handle personal data: names, addresses, phone numbers, often tax IDs. GDPR, under Article 6, requires a clear legal basis for processing this data, and Article 32 requires appropriate technical measures.
Custom software gives you concrete advantages here: you can implement proper data retention, pseudonymize where it makes sense, honor the right to erasure without depending on support tickets with external vendors, and keep auditable logs of who did what. Generic SaaS gives you all of this in theory; in practice, each capability depends on which plan you're on and how fast support replies.
Real cost: what proposals leave out
A project like this, done right, has four cost components that most proposals underestimate.
Initial development is the visible part — building the app, design, testing, going live. Typically 40% to 60% of total first-year cost.
Data migration is always underestimated. Extracting data from Excel sheets, scanned paper, old systems, and shaping it into something consistent to import takes more time than any reasonable estimate suggests. Set aside at least 15% of the budget.
Training and hand-holding during the first few weeks. The first two weeks after go-live determine whether adoption sticks. 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 cost that many companies like to pretend doesn't exist until the system breaks.
Signs it's time to do this
Concrete signals, from mild to severe, that a services company is hitting the ceiling of manual management:
- You get client calls asking about jobs and you need to ask three people before answering
- The person who runs the main Excel file went on vacation and the business slowed down
- You find out about jobs completed weeks ago that were never invoiced
- Internal arguments end with "I thought you were handling that"
- New hires take weeks to figure out where things live
- When you grow 20%, coordination gets exponentially worse instead of scaling linearly
If you recognize two or three of these signals, it's probably time. If you recognize four or more, it was time two years ago.
Key takeaways
A services business doesn't need impressive technology. It needs a system that speaks the right vocabulary, captures the real state of the work, keeps auditable history, and runs on the phone of whoever is on site.
The call between off-the-shelf and custom is a call about total cost of ownership and the real probability of team adoption. Off-the-shelf is cheaper to start; custom is cheaper to maintain and use. For critical operations, custom almost always wins over three to five years.
Migration is a change management problem more than an engineering one. Having the software ready is necessary but not sufficient. Without an internal owner with authority and without serious historical data migration, even the best system ends up half-adopted.
The next editorial piece looks at the opposite: when it makes sense to keep everything in spreadsheets and resist the pull of digitizing too early. Not every company is ready, and sometimes building a system is just another way of procrastinating on operational decisions that need to happen first.