Problem before brief
The brief is not the goal. A solved problem is the goal.
Software that fits.
Software that fitsyour business.Not the other way round.
Off-the-shelf systems unify processes — and erase what sets you apart. We design and build software around the way you actually work. First working prototype in days.
10+ years of business analysis
- commercial banking
- automotive
- hospitality
- data products
Where it breaks
Building software is not the problem. The brief is the problem.
Given a clear specification, building almost any software today is not a problem — it is a question of budget and technical limits. The problem is that the person commissioning it often does not know exactly what they want, or defines something that will not solve their problem.
Everything else follows from this: why change is inevitable, why we move in small steps, and why we start with a prototype.
First conversation
The real need
The brief
The space where misunderstandings are born
Why build your own
Buy your operations. Build your business.
Software that does not make you money can be off-the-shelf. But what sets you apart from your competitors cannot be — a ready-made product unifies your processes and erases the difference.
The closer a process is to what sets you apart in the market, the less sense an off-the-shelf product makes.
Drag it and see what follows
OperationsIt does not earn. You do it the same way everyone else does.
What sets you apartIt is your business. Nobody else does it this way.
Buy the chassis, build the rest
Part of the process is an industry standard and can be bought ready-made. What sets you apart has to be built, otherwise the difference disappears.
Scope
What we do and what we don't
Saying what we don't do is part of being credible. Here is both, without hedging.
What we do
- We design the product — from a vague need to a definition of a solution that actually addresses it.
- We build software around your processes, including SaaS-like products of our own where nothing on the market fits.
- We design and optimise processes — it often turns out that part of the problem is not a software problem at all.
- We integrate complex processes and services, and build middleware.
- We cover the whole stack from frontend to backend, including performance requirements.
- We handle the visual and graphic layer of the product.
- We run as a technology lab — testing new ways of solving problems.
What we don't do
- We don't take the role of extra hands on someone else's brief — we don't build to a finished specification without access to the person whose problem it solves.
- We don't deliver documentation and presentations as the output. The output is a working thing.
- We don't try to replace an off-the-shelf product where an off-the-shelf product is enough. Operations are not worth building from scratch.
- We don't build another generic SaaS product that is no different from the existing ones.
- We don't work as a large team of dedicated roles handing information to each other.
How we work
From a need to a working solution
- 01
We clarify the need.
We sit down with the person whose problem the product is meant to solve. We work out what is industry standard and what makes you different.
- 02
We build a business product map.
What the product has to deliver and how we will know it works. Not a technical specification.
- 03
We bring a working prototype — in days.
It doesn't have to be finished. It has to be visible, so there is something concrete to talk about.
- 04
We involve your people.
The people who will actually work in the process walk through a stripped-down but complete version of it. This is where it becomes clear what can still be improved.
- 05
We refine and hand over.
Once the concept has settled, only details remain — measured against the criteria we agreed at the start.
How we know we are there
At the start we define clear goals the product has to meet for you, and a product map with criteria for what working means. That makes it fairly simple at the end to tell what is done and what is not.
- Operational
- Tools consolidated and steps automated that a person used to do by hand.
- Financial
- Higher conversion of enquiries, more jobs processed.
Values
How we approach it
These are not aspirations. They describe behaviour you can verify on a project.
Talk to whoever has the problem
Not a delegated representative — the person whose need it solves.
Prototype instead of documentation
The first version is something you can see. Not a document and not slides.
Change is part of the plan
We assume from day one that the brief will change.
Breadth, not headcount
Product, engineering and process in one small team instead of an army of specialists.
Business outcome as the measure
The measure is the change in how the company operates. Not the number of features handed over.
About
We are not developers
We are not developers. We are not generators of documentation and beautiful presentations. We are a team that enjoys solving problems and finding ways to reach a goal, that has the technical, product and domain knowledge it needs, and that is fascinated by modern technology.
Finding a technical specialist is not hard. Finding someone with domain knowledge isn't either — most companies already have it. What is hard is finding someone who brings product, engineering and process together.
For the last twenty to forty years development was split into roles that handed information to each other. That made the process long, expensive and rigid. Today, what used to require dedicated roles and a whole development team is covered by one or two people.
Michal Radvan
Founder & CEO
Michal Radvan is the founder and CEO of Soflexity. He spent most of his career designing software and doing business analysis — in commercial banking, automotive, hospitality and data products. Over that time he kept running into the same pattern: more time spent writing briefs and explaining them to developers than on analysis and finding solutions, and the product that came out was still different from the one he designed.
LinkedIn profileI used to wait weeks for a product and end up with something other than what I wanted. Usually I had to accept it. I don't have to any more — and that is why Soflexity exists.
Soflexity Lab
What used to be off limits no longer is
We don't only implement proven frameworks and industry standards. Soflexity is also an incubator and a technology lab for approaches nobody has verified yet.
Developers deliberately avoided a whole range of things — they were too laborious or too unreliable. We are reopening them and using modern technology to push the boundary of what is realistic.
Lab scope
Graphics
Complex process integration
Middleware
Frontend
Backend
High performance
Experience
Ten years inside other people's processes
More than 10 years of business analysis across industries: commercial banking, automotive, hospitality and data products. Breadth across domains makes it possible to talk to the people who hold the domain knowledge and to ask the right questions.
10+years of business analysis
Domains
- commercial banking
- automotive
- hospitality
- data products
Reference project
In progressA hotel group
We are building a SaaS-like product of our own for a hotel group. The client chose that route because no product on the market could fully adapt to their processes and to how they want to run the business side — and to differentiate through it. Most of the options they considered would have forced them to adapt instead.
To avoid producing yet another identical system, two things had to be separated: the general industry standard, the working chassis that is the same everywhere, and the processes that make this client's business different.
Qualification
When an off-the-shelf product is enough
There is no point building custom software for standard operations you have no reason to run differently from anyone else. There, standardisation is an advantage rather than an obstacle. Custom makes sense where a ready-made product takes away what sets you apart.
When we are the right choice
- 01The process in question is part of what sets you apart in the market — not mere back-office work.
- 02You looked at off-the-shelf products and none of them could fully adapt to how you want to run the business.
- 03Your team currently works through several disconnected tools, clicking between them and duplicating information.
- 04You have strong domain knowledge but nobody who can translate it into a working product.
- 05There is a specific person with a real need who is willing to be a partner in the conversation.
- 06You need a solution quickly and can accept that the brief will evolve in the first few weeks.
When an off-the-shelf product is the better choice
- 01It is standard operational work you have no reason to do differently from anyone else.
- 02The process brings no competitive differentiation and standardisation is actually an advantage.
- 03A product exists on the market that matches the need without requiring you to change how you work.
If you are not sure which side you are on, get in touch — we will work through it together.
Get in touchQuestions
What people ask us most
A capacity supplier starts where a brief already exists. We start where the brief does not exist yet, or does not solve the real problem. We don't supply programming capacity, we supply a solution to a need — which means we talk to the client about the problem, not about a specification.
Careers
Breadth, not headcount
Finding a specialist with deep knowledge of one technical area — integrations, cyber security, regulation, performance — is not hard today. Finding someone with domain knowledge isn't either; most successful companies have it. And finding someone who can design good processes is reasonably easy too.
What is hard is finding someone who can bring all three together. At Soflexity the scope is deliberately broad.
Who we are looking for
- You combine product, technical and process knowledge — or at least two of the three, and the third one interests you.
- You enjoy solving a problem before it turns into a brief.
- You can bring a working prototype faster than it would take to describe it.
- You are drawn to approaches others avoid because they are laborious or unreliable.
We don't advertise specific roles. If the description above fits you, write to us — the role will be shaped around what you can do.
Get in touch
Describe the problem, not the brief
We don't need a finished specification. We need to know what is holding you back today and who it is meant to help. The rest is our job.
Fifteen minutes with the founder
Pick a free slot. No preparation and no commitment — we will go through your problem and say whether building your own makes sense in your case. If it doesn't, we will tell you that too.
Calendar didn't load? Open the booking page in a new window