You know your companybetter than any consultantever will.
What you need is someone who builds. Not a strategy document. Not a roadmap. A working system — built around how your people actually work, delivered in weeks, measured by whether your team uses it every day.
“I've worked with companies of 15 people and companies of 15,000. The problem is always the same. The stakes are higher when it's 15.”
I started in 1998 implementing technology in Portuguese companies — most of them small, most of them with limited patience for anything that didn't work immediately. That context taught me more about adoption than any enterprise project ever did. When the margin for error is small, you learn fast what actually matters.
What I learned: the CEO of a growing company already knows what the problem is. They live with it every day. What they don't have is the time, the technical team, or the confidence that the solution being sold to them will actually be used by the people who are supposed to use it. That gap — between knowing the problem and trusting the solution — is what I built Bitsapiens to close.
The research behind this approach — the frameworks for AI-Human systems, the thinking on how organisations need to evolve to absorb technology without breaking — lives at amartins.io. It is where I think out loud before anything becomes a product. If you want to understand why we work the way we do, that is where to start.
Built for companies that can't afford for technology to fail.
A large company that buys the wrong system loses money and writes a report about it. A company with 20 to 200 people loses months of momentum, a demoralised team, and often a significant portion of its annual technology budget — with nothing to show for it.
We built Bitsapiens for the second type of company. Not because enterprise clients aren't interesting — but because the stakes are higher, the margin for error is smaller, and the people we work with are closer to the problem than anyone else in the room.
We are not consultants who advise. We are builders who create alongside you — from the first conversation to a working system your team actually uses. We measure success the same way you do: by whether it works, and by whether anyone is still using it six months later.
“Most technology fails not because it doesn't work. Because nobody mapped how the people were actually going to use it.”
The finance team still processes invoices by hand on Friday afternoons. The sales director still maintains the pipeline in a spreadsheet only she understands. The CEO still reads data that is three weeks old.
The system exists. Nobody uses it. The problem persists.
We fix the reason for that — before writing the first line of code.
Three things we do
that most don't.
We start with the problem, not the tool
Most technology vendors start with their product and find a way to apply it to your situation. We start with your situation — who does what, where time disappears, what the team actually does versus what the process document says they do. Only after this is understood do we decide what to build. This is the step that determines whether the system gets used or sits idle.
We build what you see before you pay for what you get
Before any significant commitment, we build a working prototype on your real data. Not a demo, not a mockup — a system connected to your actual processes. Your team tests it. If it doesn't solve the problem well enough, you walk away. If it does, we discuss what full implementation looks like. This is how we think it should work — and how most technology purchases should work, but don't.
We measure success by adoption, not by delivery
Delivering a system is not the same as solving a problem. We stay involved after deployment — training teams, measuring real usage, adapting what isn't working. Because a system that gets delivered and abandoned is not a success. It is a more expensive version of the problem you had before.
25 years of the same problem. Finally, a different answer.
In 1998, António Martins began implementing digital transformation projects in Portuguese companies. The systems were simpler. The budgets were smaller. The fundamental problem was identical to what he still sees today.
Technology installed into organisations that were not redesigned to receive it. Warehouse teams who continued managing stock in notebooks because the ERP was too slow to navigate in the middle of a workday. Finance teams who maintained parallel Excel files because the official system required three extra steps for every transaction. Sales directors who kept the real pipeline in a spreadsheet because the CRM reported what should have happened, not what actually did.
“The system works. The people don't use it. And everyone pretends the problem is the people.”
The problem was never the people. The problem was that nobody had observed how they actually worked before designing the system they were supposed to use. And nobody stayed long enough after delivery to find out why adoption had not happened.
After 25 years of seeing this pattern in companies of 15 people and in companies of 15,000 — the conclusion is the same. The order matters. Start with the people. Understand what they actually do. Then build something that fits that reality. Everything else is implementation detail.
Understand →
co-create →
build →
evolve.
Every project follows the same four-phase process — because each phase addresses a specific failure mode that causes most digital projects to disappoint.
Understand
We start with observation, not assumptions. Who does what? Where does time disappear? What workaround exists because the official process doesn't work? This is the phase most projects skip — and the phase whose absence explains most failures.
Co-Create
Together, we shape the solution through iterative prototyping. When users shape the product rather than signing off on a requirements document, the product that emerges reflects their reality — not our interpretation of it.
Build
Development in two-week cycles with real users testing and redirecting at every iteration. The system that gets delivered is the one refined through actual use — not the one designed in advance and discovered to be wrong on delivery day.
Evolve
Products are never finished. Technology changes. Organisations change. We stay involved after deployment to train teams, measure adoption, and adapt the system as the reality it was built for continues to develop.
Distributed intelligence.
Our team spans multiple locations — deep expertise with geographic breadth. Clients in different markets receive genuine local context, not timezone-adjusted service.
Questions we hear before every engagement.
We are a company of 30 people. Is this for us?
Yes — and this is the size of company we work best with. Between 15 and 200 people, the CEO is close enough to the problem to describe it precisely and far enough from the day-to-day to see the pattern. The minimum investment for an engagement is typically €8.000–€12.000. Most of our cases were delivered between €9.500 and €28.000, depending on complexity.
We've bought technology before that nobody ended up using. How is this different?
We start with observation, not assumptions — understanding how your team actually works before proposing anything. We build a working prototype on your real data before you make any significant commitment. And we stay involved after delivery to measure adoption and fix what is not working. Most failed implementations skip at least two of those three things.
We don't have an internal IT team. Can we still work with you?
Yes — and most of our clients are in exactly this situation. We own the technical side completely. You do not need to manage developers, understand architectures, or translate between business and technology. Your job is to describe the problem and give us access to the people who have it. Our job is everything else.
How quickly can something be working?
In most cases, a working prototype is ready within 72 hours of our first conversation — on your real data, connected to your actual processes. Full implementation typically takes 4 to 12 weeks depending on the complexity of the problem. We have never delivered a project that took longer than 14 weeks from first conversation to system in production.
Have a problem that is costing you time or money every week?
Tell us what it is in plain language. We will tell you if we have seen it before — and what solving it looked like.
DESCRIBE THE PROBLEM →