Studio
when you know what you need built
Custom software, websites, internal tools, ERP, automation, AI implementation, cloud work and robotics. We scope it, build it at our own desks and stay on it after launch.
About WMinus
One company, four years of it. Studio work, consulting and a venture arm, all run by the same engineers. We started in 2022 with more ambition than staff, the work now goes out across Europe, and we are still hiring to keep up with it.
The engineer who answers the first email writes the code, and is still on it when it needs changing two years later. Everything below is what that arrangement costs and what it buys.
01 / Choices
Made early, kept when they were inconvenient, and each one costs us something.
The ERP work sits on an open-source core we hold the source for. The AI work runs open-weight models on hardware the client owns. Repositories, servers and registries end up under accounts the client owns, not ours. We do not run a hosting business, so there is nothing here to lock anyone into.
A large part of the robotics and integration work is reading data out of equipment a vendor stopped supporting: CNC controllers, Omron PLCs, arms with proprietary interfaces. The alternative usually on offer is a new machine. Getting another decade out of the one already on the floor is the cheapest option available to a plant, and incidentally the environmental one. Same instinct one level up, which is why this page weighs a few hundred kilobytes and tracks nobody.
Consulting is free for students and nonprofits. In practice that is competition teams two weeks before a deadline, faculty projects, and questions from people who will not be hiring anyone for years. Same engineers, same address as everyone else, no invoice at the end.
Ask about any of these on the first call. The people who decided them are the ones on it.
02 / Origin
WMinus was registered in 2022. The plan was not modest: build software properly and in-house, for companies used to buying it from somewhere else. There were far fewer of us then than there are now.
The small market turned out to be a useful constraint. Every project is a reference, good or bad, and there is no room for a company that only performs well in a slide deck. The early work was the work a small market has. Websites. Internal tools. Processes still running on paper, or on the one spreadsheet nobody in the building dares touch. None of it glamorous, all of it load bearing.
We built everything in-house from the first project, mostly because there was nobody to hand it to. We kept doing it after we could have afforded not to, because by then we had seen what happens to a codebase that three companies have taken turns on.
Four years in, the studio work, the consulting and the venture builds all run at the same time, which is more than a company this size is supposed to take on. We take it on anyway, we are hiring to keep up with it, and some of it is genuinely hard. That is closer to the truth than saying it all runs smoothly.
03 / How you can work with us
Most companies pick one of these and build a brand around it. We do all three because the work keeps asking for it: somebody hires us to build a system, then asks whether the plan was right in the first place, then comes back two years later with an idea and no team.
Studio, consulting, venture build. One in-house team underneath all three.
when you know what you need built
Custom software, websites, internal tools, ERP, automation, AI implementation, cloud work and robotics. We scope it, build it at our own desks and stay on it after launch.
when you need to know whether to build it at all
Architecture reviews, build-or-buy calls, AI feasibility, second opinions on a quote someone else gave you. Senior engineers, email first. Free for students and nonprofits.
when you have the idea and no team
We build the product and take a share of the upside instead of the full fee: equity, revenue share, or a reduced fee plus a stake. Several products already run this way. It is not free work, and it is not an accelerator.
04 / How we work
The engineer in the scoping call is the engineer who writes the code, and the one who answers when something misbehaves two years later. There is no handover document here, because there is no handover.
We pick tools with long and uneventful maintenance histories over whatever had a good week on the internet. Software you own has to survive its own success, three upgrades and the developer who left.
Every project we regret started out large. So the first version gets cut down to the part that has to work, shipped, and actually used. Everything after that earns its place against something real.
Scope, decisions and trade-offs go in writing, in words a non-engineer can argue with. If we cannot explain why a thing is being built, that is usually a sign it should not be.
Nobody has ever thanked us for a clever abstraction. They thank us for the thing that still works when we are not in the room.
05 / Where we work
Where the company is registered and where most of the desks are. Small enough that every project is a reference and a bad one follows you around, which is a useful thing to have learned early.
The neighbours. Close enough to be on a factory floor in the morning and back at a desk the same day, which matters more than it sounds when there is hardware in the room.
Manufacturers, service companies and the systems that hold them together. Mostly remote, with visits when a machine has to be seen rather than described over a call.
The far ends of the map so far. European infrastructure, European rules, and a client list that keeps stretching further from home than we planned. This part is still growing, which is the honest version of expanding.
06 / The range
The same team that ships a website also programs a six-axis arm to pick a part out of a bin, wires a PLC into an ERP, and runs an open-weight model on hardware the client owns. The range is not a menu we grew to look bigger. It is the shape of the work: a manufacturer who wants a customer portal usually also has a machine nobody can get data out of, and the two problems turn out to be one problem.
Client work is anonymized here on purpose. Industries yes, names no, unless somebody asks us to say theirs out loud.
More detail lives on software, web, AI and robotics, and the odd experiment ends up in the research lab.
07 / The people
Engineers mostly, plus the people who stop projects from quietly drifting. We do not publish names or faces on this site. You meet the people who will build your system in the first call instead, which is more useful than a grid of portraits.
Working with us is fairly plain. You get engineers in the room rather than an account manager relaying questions. Estimates come with the reasoning attached. When something is a bad idea, you hear that before the invoice, not after.
We hire regularly, and not always for the role we thought we were advertising. Before you write, the honest description of the job:
Send something you built. A repository, a link, a thing that runs. A CV is fine too, it just gets read second. The address is info@wminus.com, and a person reads it.
/\_/\ // resident cat. writes no code, ( o.o ) // reviews everything anyway, > ^ < // has opinions about the ERP.
P.S. the console has a message in it, and the Konami code works on this page too.
08 / Students and young engineers
We answer questions from people who are not clients and are not going to be for years. We help student teams with the specific thing that is broken two weeks before a deadline. It is the part of the work that does not invoice, and a company that only does the part that invoices gets dull quickly.
The same engineers and the same email address as everyone else gets, without the invoice. Architecture questions, build-or-buy calls, a second opinion on a plan somebody else wrote. Write to info@wminus.com and say which one you are.
Competition teams, faculty projects, the robot in the basement that worked yesterday. We help where help is actually useful, which is usually one specific technical problem and not a mentoring programme with a certificate at the end.
4 Students is where the teaching side lives, at education.wminus.com. Early and still being built, which is true of most things here that we are proud of.
If you are young and you already build things, say so. We would rather hear from you three years before you are ready to be hired than not at all. A side project you can show us counts for more here than a transcript does.
09 / What we have to show for it
Autonomous robots designed, built and programmed by the same people who work on client systems: chassis, sensors, vision, control loop and the software on top. Competition floors are unforgiving in a way a demo never is. A machine either crosses the room or it does not, and that habit is what shows up later on a production line.
How that shows up on a production lineCertificates held by us and by the providers we build on. SOC 2 and ISO 27001 cover audited security practice, ISO 27701 and GDPR cover how personal data is handled, and the EU AI Act mark covers building AI the way the regulation expects.
Newsletter
Occasional writing about how we scope, build and ship software. No campaigns, no drip sequences, and you can leave in one click.
Rough is fine. A paragraph and a rough deadline is enough to start a useful conversation. A person reads it, not a funnel.
Not ready to talk? Read what we write on the blog, or look at how Venture Build works.