Decisions are tested against the code, data, integrations and real operating conditions as the project progresses.
SOFTWARE ENGINEERING STUDIO · BARCELONA
Fewer layers between a technical decision
and its consequences.
Rabassoft is a founder-led software engineering studio for companies that need to build or modernize software that matters to their business. The studio is intentionally small so context, technical leadership and implementation remain connected throughout the engagement.
STRUCTURE / PURPOSE
The structure is designed to increase responsibility, not to multiply layers.
Rabassoft does not try to look like a large consultancy. The founder-led model reduces the distance between understanding the problem, making technical decisions and bringing them into production.
Size alone is not an advantage. It becomes one when it helps preserve context, make decisions visible and maintain clear technical accountability from start to finish.
Important context does not need to pass through a chain of roles before reaching the people who must turn it into a decision or an implementation.
A tool, framework or AI agent can help execute work. Decisions and acceptance still have an identifiable, accountable owner.
TECHNICAL OWNERSHIP
The same context should carry through to the code, verification and the next decision.
Separating strategy from delivery loses information precisely where real constraints emerge. We treat the engagement as a continuous whole: understanding, deciding, building, verifying and evolving all belong to the same system of accountability.
See the engineering process- 01CONTEXTUnderstandBusiness · system · constraints
- 02DECIDEDecideOptions · trade-off · risk
- 03BUILDBuildArchitecture · implementation · integration
- 04VERIFYVerifyEvidence · behavior · quality
- 05EVOLVEEvolveProduction · feedback · continuity
LEGACY MODERN
The most useful specialization is not in a framework. It is in building the transition between generations of software.
Many important systems do not begin with a modern architecture and cannot be replaced as if they were greenfield projects. Rabassoft works in that transition space: understanding what exists, preserving what matters and deciding how to move towards a foundation built to evolve.
WHY / RABASSOFT
The difference should be visible in how decisions are made and carried through.
Experience working across generations of software—and especially in designing the transition between them without losing the knowledge that supports the business.
Those involved in technical decisions remain close to the implementation, verification and actual consequences of those decisions.
We do not turn uncertainty into an apparently precise date, scope or budget just to facilitate a sale. First we make explicit what can be defended.
The context, decisions and important deliverables should be able to continue with Rabassoft, an internal team or another provider.
CAPACITY / WITHOUT FICTION
A small structure does not mean that everything should be done by one person.
Core technical leadership and accountability remain founder-led. When a project needs additional capacity or specialist expertise, it can be added explicitly and managed without turning the client into the coordinator of an opaque network.
We do not sell a predefined team before understanding the problem. Who is involved, why they are involved and what they are accountable for must remain visible.
Context · decisions · architecture · responsibility
Added with explicit scope and responsibilities.
Without presenting project-specific capacity as a permanent structure.
CONTINUITY / WITHOUT LOCK-IN
Trust should not depend on Rabassoft being the only party that knows how the system works.
A small structure also means taking continuity risk seriously. The answer is not to pretend the risk does not exist, but to reduce it through explicit context, recoverable decisions and deliverables that can continue beyond Rabassoft.
How we structure a collaborationThe current project state should not exist only in meetings, chats or personal memory.
Important decisions retain alternatives, constraints and consequences, not just the final outcome.
The assessments and technical artifacts are designed to have value outside the commercial relationship with Rabassoft.
A healthy engagement allows you to change teams without first rebuilding all the system knowledge.
ENGINEERING / LEVERAGE
Tools can change, responsibility can't.
We use automation and AI when they help us understand a system, analyze more information or accelerate repetitive work. They do not replace architecture, review, testing or accountability for the outcome.
How we use AI- 01CONTEXTExplicit contextState · decisions · constraints
- 02SCOPEBounded accessData · tools · permissions
- 03VERIFYEvidence before acceptingTests · review · verification
- 04HUMANHuman accountabilityDecision · acceptance · production
START / CONVERSATION
Looking for someone who can connect technical decisions with delivery?
Tell us what you need to build, which system needs to evolve or which technical decision still needs definition. The first conversation helps us understand the context and assess fit.