Paulo Serrano · DigitalDev
I have been a developer for 25 years and I founded DigitalDev. I spent more than two decades inside a public institution operating at national scale, on projects larger than most private companies ever touch. I bring that background to a much smaller and far more common problem: getting out of one person's head the things a company ought to know how to do on its own.
Half an hour · no strings attached
Who is speaking
I founded DigitalDev, and I am involved as a partner in projects run with other companies — SingularVision and Codeboys. I send invoices at ten at night, I stay close to every client, and I pick up when someone needs help on a Sunday. Not out of heroics: because I know exactly what it is to run a small or mid-sized company — the operation does not stop at the weekend, and on either side of it there is nobody to hand the problem to. I am not writing this to seem relatable. I am writing it because it is the only credential that matters here: I use what I build.
Alongside that, I have spent more than twenty years inside a public institution operating at national scale. That is where I learned what scale actually means: processes serving thousands of people, integrations between nationwide systems, platforms built from scratch and maintained for years. The difference in size compared to a small company is enormous; the nature of the problem is exactly the same.
I have worked in healthcare, accounting, systems certified by government bodies, manufacturing, marketing and retail. I have integrated ERPs — ArtSoft, PHC, Devlop.System, SAGE — and systems nobody has updated in twenty years. It is an unglamorous track record, and that is precisely why it is worth something.
Almost none of what I have fixed makes for a good slide. At a clinic, bookings depended on somebody picking up the phone: they started coming in at any hour, with the confirmation and the reminder going out on their own, and no-shows stopped being a Monday morning surprise. At a company invoicing by hand, every document started coming out compliant with the tax rules without anyone needing to know what a document series or a validation code is.
Somewhere else, shipping costs were a rough guess made at the counter — sometimes in the customer's favour, sometimes against — and became a figure calculated on the spot, by weight and destination. Somewhere else again, half the support emails were the same question: where has my order got to. They stopped arriving once the answer was there without having to ask.
None of these started with someone asking for software. They all started with someone saying "this takes me the whole morning". What is left at the end is not the technology: it is the morning.
So most of the times I am called in to "build something", the answer is not to build anything at all. It is to change two steps of the process. I say so even when it does not suit me.
Sound familiar
01
And that person has been off sick for three weeks. Nobody opens that file without ringing them first.
02
Because the only way to know what is in the warehouse is to ask someone who would also rather not be looking at their phone at that hour.
03
So payroll goes out on time on Monday. Every Friday. Always the same person.
04
And now three people are asking each other who had it last.
05
Orders, complaints, out-of-stock warnings — it is all in there, scrolling off the screen, and nobody can retrieve what was said two months ago.
06
And takes with them, in their head, the only complete map of how the thing actually works. Nobody ever wrote it down.
If a system only works because one person remembers everything, that is not a system. That is that person.
Three things I have seen
The spreadsheet
Nobody designed it on purpose — it grew, year after year, on the back of one person who understood the problem and solved it alone. It works. Until that person takes a fortnight off and their phone starts ringing from the airport. That is when the real price of the spreadsheet becomes clear: it is not what it cost to build, it is what it costs to have nobody else who understands it.
The Friday meeting
The silence that follows is not hesitation — it is searching. One checks email, another checks WhatsApp, a third rings the warehouse to ask the colleague who wrote it on a scrap of paper. A number arrives ten minutes later, with a margin of doubt attached. Nobody questions why. Everyone has long accepted that this is how the company remembers itself.
The notebook
I walk into the warehouse and find a notebook lying next to the computer — that is where the things that matter get written down. The system looks good in reports; the notebook is the one that never fails. I asked why. "It is quicker," they told me, without looking up. They were not being lazy. They were being honest.
The image
This image is not mine. It is what comes up when you type "automation" into a stock photo library: blue cogs meshing perfectly, everything connected to everything, a finger touching the future. In 25 years I have never walked into a company that looked anything like it.
What I find is a notebook next to the computer, three files with the same name and different dates, and someone apologising for the mess before showing me how things actually work.
There is no need to apologise. That is precisely why I am there.
Why me
01
I am not a manager who learned to talk about technology two years ago. I have been building software for 25 years and I still do — I do not delegate the part that matters to people who have never done it.
02
More than two decades inside a public institution operating at national scale: integrations between large systems, processes with thousands of users, platforms maintained over years. I bring that level of rigour to problems of a very different size.
03
I founded DigitalDev and I work in partnership on other companies' projects. I send invoices, I chase late payments and every month I decide where I am not going to spend. Whatever I propose to you, I had to solve for myself first.
04
Invoicing certified by the Portuguese tax authority, systems certified by government bodies, ERP integrations — ArtSoft, PHC, Devlop.System, SAGE — and web services nobody has updated since 2006. That is the ground I work on every day.
05
I maintain open-source packages for invoicing, payment and error-tracking integrations. This is not a claim — it is public, and any developer can open it up and check how it is built.
I built for my own operations nearly everything I propose to others. Not out of conviction — out of necessity.
The hard part is never writing the code. It is the meeting where someone admits that nobody knows how the thing works.
How I work
01
You tell me how it works today, not how you wish it worked. Half an hour is enough to know whether it makes sense to carry on.
02
I follow the real path of an order, an invoice, a shift — not the flowchart that exists only in somebody's head. I note where the time goes, and where the information goes with it.
03
Written in plain language: what is costing you time, what can be simplified without touching anything, and what genuinely justifies being automated.
04
You can keep just the map. You can fix half of it yourself. If you want me to build whatever is left, we discuss that separately — never before.
What I do not do
Sometimes the right answer is to change two steps and buy nothing at all. If that is the case, I say so — even if it ends the conversation there and then.
A map that always ends in "and now I will build it for you" is a sales pitch dressed up as a diagnosis. If the right tool already exists off the shelf, that is the one I point you to.
I dislike the phrase, I do not use it, and I am wary of anyone promising it in a one-hour meeting. What I do is quieter and more useful: taking hours off someone's plate.
If I quote you a percentage or a "so many hours a week" before seeing your process, I am making it up. I would rather measure first and talk afterwards.
The conversation
I do not know whether what your company needs is a new system. Honestly, more than half the time it is not. But if there is something eating your Saturdays that no longer should — a spreadsheet, a notebook, one person who is the only one who knows — tell me about it.
I do not promise a solution. I promise to look carefully before saying anything at all.
No strings attached · no 40-slide proposal
> COOKIE_CONSENT_REQUIRED
Utilizamos cookies essenciais para o funcionamento do site e cookies analíticos (Google Analytics) para compreender como utiliza o nosso site. Os cookies analíticos só são ativados com o seu consentimento. Política de Privacidade