[Table of contents]Show table of contents
In 2016, on a napkin with Krzysztof P., a Cupra dealer in Kraków: a 200k PLN VIN-tracker in Excel. That’s how Do More Soft started. Today we have 12 proprietary products, a team of over a dozen specialists, and more than 80 completed projects. The road wasn’t linear, and that’s exactly why it’s worth telling.
The beginning: automotive as a school of survival
The first serious project was a system for a car dealership. Factory integration, VIN tracking, financing calculator. Automotive taught us two things: complex business processes demand deep domain understanding, and clients don’t want “software.” They want their problem solved. That lesson defines us to this day.
In the first 18 months we delivered projects, money was tight, and we didn’t know what the client did with the code afterward. It felt like failure even though the invoices said otherwise. A linear, predictable model — but a capped one. We were missing a sense of co-ownership over what we built.
The turning point: deciding to build our own products
In 2020 I had a dilemma. Hire devs and sell hours, or build a product. The choice made itself when we narrowly lost a 300k tender. That’s when we started building our own products. Not because we ran out of clients. Because we kept seeing the same problems across many companies and knew we could solve them systemically.
It was a risky move. Building proprietary products demands an investment of time, money, and energy that could otherwise go to commercial work. But it gave us something no client engagement ever will: skin in the game. When you build a product you have to maintain and grow yourself, you make different architectural decisions than when you hand off code and walk away.
How does a software house differ from a venture builder?
A classic software house carries a hidden conflict of interest: the longer the project runs, the more it earns. A venture builder earns on product success, not on hours burned. A fundamental difference in incentives that flows into every decision — from technology choice to MVP scope.
When we build a product on our own dime, we have to be ruthlessly pragmatic. No room for overengineering, because it’s our money. No ignoring user feedback, because they’re our customers. No build-and-abandon, because it’s our P&L. That discipline carries into client projects. We learned to think like owners, not subcontractors.
Venture Builder vs. Software House: key differences
| Dimension | Software House | Venture Builder |
|---|---|---|
| Revenue model | Invoiced hours | Product co-ownership, equity, success fee |
| Decision horizon | Until delivery | 3-5 years of production operation |
| Architecture | For demo and handover | For maintenance and scaling |
| Estimates | Optimistic (to win the tender) | Realistic (we’ve built similar) |
| Scope decisions | ”Client wants it, we build it" | "MVP or nice-to-have?” |
| Skin in the game | None after deployment | Three years after deployment |
12 products — what we build and why
MoreSales was born out of frustration. MyCarApp because Cupra taught us dealerships. OpenEZD because public administration personally exhausted me. That’s how most products in the ecosystem are born: not from a research deck, but from pain someone on the team saw up close.
The ecosystem covers MoreSales and MoreCRM (CRM/ERP), industry platforms — MyCarApp for automotive, DailyHair for beauty, CalMedic for medtech, Kwadracik for real estate — document workflow (OpenEZD, MoreGenerator), AI and content (Textio), plus tools MoreNFC, MoreMobile and GetMeCon.
DailyHair is a good example of venture building in practice. The beauty industry needed a booking system that isn’t a generic Booksy. A system that understands the specifics of hair salons and barber shops. We built it, deployed it in pilot salons, iterated on feedback, and are scaling it as a standalone product.
What does skin in the game mean in software partnerships?
A client who comes to a software house gets a team that wrote code. A client who comes to a venture builder gets a team that built, launched, maintained, and scaled its own products. The difference is operational experience. We know what happens after deployment, because we live off what we deployed.
Concretely it means: realistic estimates (we’ve built similar systems on our own dime and know how long things take), architecture designed for maintenance instead of for demos (we maintain products for years ourselves), and pragmatic scope decisions (we know what’s MVP and what’s nice-to-have because we’ve made those same calls for ourselves many times over).
Lessons from a decade of building
First lesson: perfection is the enemy of shipping. Better to ship a solid 80% than a perfect 100% that never reaches production. Second: technology is a lever, not a goal. The client doesn’t care whether you use React or Vue. They care whether the system solves their problem. Third: the team matters more than the stack. A good developer on average technology delivers better results than an average developer on the latest one.
The hardest lesson: say “no.” In 2023, a client with a 500k budget for a logistics SaaS. I said no. We don’t have a domain expert. We don’t have references. A badly fitted project costs more than no project at all. A tough lesson for a company that wants to grow, and a defining one for a company that wants to grow wisely.
Vision: what’s next
We don’t want to be HR for software. We want to be product operators who know what happens in year three, because we’re already there. The model: a venture builder that shares risk and reward with partners, instead of invoicing for hours.
Over the next two years we plan to grow the ecosystem to 15-18 products, push harder into the DACH and CEE markets, and build a technology platform that lets us launch new products faster — with a shared layer for authentication, payments, analytics, and infrastructure. We’re not building a software house. We’re building a machine for creating digital value.
FAQ
How does the venture builder model differ from classic development?
Classic development means invoices for hours. A venture builder earns on product success — through co-ownership, equity, or a success fee. That changes every decision: from the stack to MVP scope, from architecture to SLA.
Why do venture builders make better architectural decisions?
Because they live with the consequences. A software house hands off the code and sends an invoice. A venture builder maintains the product three years after deployment, so it won’t build something it doesn’t want to nurture. Decisions are pragmatic, not showcase.
Does Do More Soft also work on a project basis?
Yes, but selectively. We take on projects where we can apply know-how from our own products — automotive, beauty, medtech, GovTech, real estate. “Anything, as long as it’s a programmer” projects we turn down.