Monday Merch · Rotterdam · One hire

A technical product builder and lead.

Own the software that runs a €27m company. Four years old, profitable, seven engineers, one ERP that 210 people live in. It needs one owner.

Hiring manager: Daniel Salimian, founder. You would report to me directly.

The role	A technical product builder and lead. That is the one-line version, and it is the one to judge yourself against.
Title on paper	Head of Engineering, or Head of Technology. Whichever you would rather have on a business card.
Reports to	Daniel Salimian, founder. Directly, with no layer in between.
Location	Rotterdam, five days a week. This is an in-person job and we are not flexible on it.
Team	7 core engineers, plus everyone else in the company we can give safe tools to build with.
Hands-on	30–50% of a normal week is your own code. Part of the role, not something we tolerate on the side.
Final say	Delivery, architecture, releases, vendors, engineering hiring. Mine until month four, yours after that.
Hours	Full time.
Compensation	€80,000 – €100,000 a year. That is €7,000 – €8,000 a month.
Start date	As early as you can make it.
To apply	Five minutes now. Another thirty if we both want to continue. No CV needed to start.

Start the first round daniel@mondaymerch.com

The company

Not a technical industry. That is exactly why it is interesting.

Most of promotional merchandise in Europe still runs on email, spreadsheets and PDF proofs. We are building software instead.

We print, embroider, pack and ship physical products — at volume, to deadlines, for companies that care a lot about whether their logo is exactly the right green. Every order carries artwork, print positions, colour matching, minimum quantities, lead times and a carrier. Almost none of that is solved by software today. This is not a CRUD problem. The physical side makes nearly every workflow harder than it looks on paper.

We are profitable and we have no investors to keep happy. Nobody here is building towards a funding round. The only question we ask is whether the software makes the company measurably better.

€27mRevenue

4 yearsSince we started

~7×Order growth since 2023

10–15%EBITDA · profitable, no VC

7Core engineers

210+People in our internal tools every day

~6,000Orders signed, last 12 months

4,000+Business customers, last 12 months

ISO 27001Certified, and staying that way

In 2023 we signed 882 orders. In the last twelve months we signed around 6,000, for more than 4,000 different business customers. The team did not grow at anything like that rate, and the software is a large part of why that was possible.

What you own

The whole technical system, and the team that builds it.

Shop and website — build, run, performance, infrastructure
Design Studio and Brand Hub — delivery, architecture, what is technically possible
Platform — our customer portal: reorders, sharing, self-service
Odoo, our ERP — architecture, data model, standard versus custom
Integrations — carriers, finance, vendor catalogues
The production line — review, staging, security, audit trail
AI and automation — in the dev loop and in production
Cloud infrastructure — GCP, releases, reliability, cost
Technical security — ISO 27001, and keeping it
The team — 7 engineers, hiring, budget, practices, standards

You lead 7 core engineers directly, and indirectly everyone else in the company we can hand safe tools to. 30–50% of your week is your own code — mostly foundations, tooling and paved paths that raise everyone else's output.

What you do not own is what gets sold. Direction on the customer-facing surfaces comes from growth and sales; demand for internal systems comes from operations, sales and finance, who carry those numbers and often build the first version themselves. You decide how it gets built, in what order, and you deliver it. You consolidate all of that demand into one executable roadmap, and you are expected to push back hard on value, feasibility and coherence.

The part most candidates have not done

Seven engineers cannot write all the software this company needs. So we stopped trying to.

Instead we are building a software factory: tooling, context, guardrails, review and deployment, so that people who are not engineers can ship real things without putting production at risk. It is not buying everyone a chat licence. It is an operating model, with three tiers of contribution and different controls at each tier.

Tier 1 Team automations

Three Eyed Raven, our agent in Slack. Anyone can ask it a question, pull a report, or have it execute work across our tools, mainly Odoo, our ERP. No engineer in the loop. The guardrails are the tools it has and the data it can reach, not a person standing in the way.

Tier 2 Reviewed internal tools

Growth builds the first version of a feature. An ops lead builds the thing that saves her team six hours a week. It becomes real software: a named technical owner, code review, tests, a controlled deployment. Most of the leverage sits here, and it is also where things go wrong if nobody designs it properly.

Tier 3 Production systems

Anything touching customers, money, security or core operations. Engineering owns it, engineering approves it, engineering carries the pager. No exceptions — also not for founders, and also not for me.

This is not a side project. The people who carry our commercial and operational numbers already build their own first versions — you run the production line that everything from every domain passes through. The job is to make that fast and safe, not to stand in the doorway. An ops lead who safely ships her own tool on a Tuesday is worth more to us than a hire we make in Q4.

The work

A few of the problems that are actually hard.

A selection, not a list. New ones appear every month, and all of these will still be open on the day you start.

Customer journey One order can ship to fifteen destinations, across VAT regions, anywhere in the world. Our catalogue has rich structured data behind it, and we still let customers order things that are not in it at all. Every step multiplies the one before it. Hard because the easy path and the exception have to be the same system

Pricing Every price is calculated, never looked up. Sales factors, add-ons per decoration, graduated pricing that moves with quantity. It has to be right the first time, in front of a customer, sometimes for a product that does not exist yet. Hard because the inputs change per customer, per quantity, per decoration

Design Studio Figma for the merch industry. Customers and our designers build print-ready artwork in the browser. It has to feel like a real creative tool while only ever allowing what production can actually make. Hard because creative freedom sits inside hard physical limits

Operations Multiple warehouses, with real routes running through them. In-house manufacturing, packing, storage and shipping across several locations. Stock takes a different route depending on what is being made, where it is going, and who is making it. Hard because a mistake here is a pallet, not a bug report

Invoicing Downpayments first, then invoices for whatever actually got delivered. Customers pay up front for something not yet produced. Delivery is sometimes partial, sometimes changed, sometimes late. The final invoices have to reconcile against all of it, in the right VAT regime. Hard because the money has to match physical reality exactly

The chain A quote has to reach production, stock, warehousing and invoicing without a person carrying it. Each has its own state, timing and failure modes. Making a change in one show up correctly in all the others is most of what our platform actually does. Hard because the difficulty is in the seams, not the parts

The stack

What you would actually be working in.

ERP	Odoo, Python, PostgreSQL, heavily extended. Our internal platform — orders, stock, purchasing, manufacturing, invoicing and logistics all live here, and 210+ people are in it every day.
Shop	Nuxt. Public catalogue, configurator, checkout, order tracking.
Platform	Vue. Our customer portal — order management, reordering, sharing and self-service.
Shared	A design-studio package and an auth package used by both frontends.
Infrastructure	GCP · Docker · blue/green releases · Cloudflare · BigQuery and a Postgres read replica for analytics.
AI	Agents in the development loop and in production workflows. Not a pilot, not a lab.
Integrations	DHL Express, FedEx, UPS, Sendcloud, Ship24, Exact, XD Connect, Midocean, Shopify, Coupa punchout, Mollie, Mailerlite, Trustpilot, WhatsApp, Framer.

None of this is greenfield. Four years of decisions are in there, and some were right at the time and are wrong now. I would rather write that here than have you find out in week two. The upside is real: you would take over a system that already carries a whole company, so anything you improve has immediate, measurable effect. I think that is a far more interesting starting position than an empty repository.

The handover

A handover only works if the authority moves, not only the tasks.

Many founders say they want to step back. This is the schedule we have committed to, in writing, before this posting went out.

Day 1 – 60 Documented handover

I am your sponsor and line manager
Material decisions made jointly while people, systems, architecture and roadmap transfer
You agree the operating model, roadmap and budget with me

Month 3 – 4 Authority transfers

You have the final call within the agreed strategy and budget
Everyone on the team reports through you
I stop tasking people and stop managing them
My code goes through your review and release process, like everyone else's

Month 6 onward Independent function

Routine priorities, architecture, hiring, releases and incidents no longer need me
You keep reporting to me, and that does not change what you decide
I stay a board-level technology sponsor. No shadow reporting line, no back channel

All founders agreed to this in writing before this posting was published — specifically the part where there are no shadow priorities and no founder overrides outside the agreed governance. I wrote it down because I know how easy it would be to say this and not mean it.

How the role is measured

Dials you own, and two outcomes you share.

We are not a SaaS company. Our software is not the thing customers pay for — it is the machine that makes designing, producing, storing and shipping merch faster, cheaper and stickier. That has a consequence worth stating plainly: you are accountable for the dials you actually turn, and not for the ones you do not.

Owned Yours alone. You turn these dials.

Uptime and incident rate
Site speed
Deployment lead time
Time from a domain build to production, meaning how fast you review and release
Infrastructure cost as a share of revenue
Team cost
Security posture

Not yours Deliberately, and we will not move them onto you later.

Revenue
New logos
Marketing results

You do not run the campaigns and you do not close the deals. Holding you to a number you cannot move is how these roles go wrong.

No story points, no headcount, no lines of code. The exact baselines and weighting we want to agree with you in the first 60 days, together with Finance. If you have strong opinions about how a role like this should be measured, bring them to the first conversation — that is a useful thing for us to hear.

Fit

Who we are looking for, and who we are not.

Industry experience helps but is not essential. We weight recent building, product ownership, small-team leverage and mature handling of founder dynamics far higher than knowing anything about promotional merchandise.

The person we have in mind

Probably was a technical founder, a hands-on Head of Engineering or Head of Technology, a VP Engineering who still writes code, or a principal engineer who has actually led people.
Has shipped meaningful production code, recently. Reviewing pull requests does not count.
Has owned both customer-facing surfaces and the internal operational systems behind them. Both halves matter here.
Has led a compact team, and grew its output through leverage rather than headcount.
Came from tech-enabled commerce, logistics, custom manufacturing, operational marketplaces, food and delivery, retail operations — anywhere physical reality complicates the software.
Is mature enough to take real authority from a founder and use it independently, including against that founder's own preference.

Please do not apply if

You have not written meaningful production code in several years. This role is 30–50% hands-on and we are not flexible on that.
You measure your own seniority by team size or budget. We grow when leverage or a capability gap justifies it, and not otherwise.
You think AI enablement means buying everyone chat licences.
You would refuse non-engineer contribution outright — or wave it through without any controls. Both answers are wrong for us.
You would need a separate product lead, an architect, an engineering manager and a security lead before you could start.
You want the title more than you want to build.

I started building the software here because there was nobody else to do it. Four years later there is a shop, a Design Studio, a customer platform and an ERP that the whole company runs on, and a team of engineers who are good at what they do. And I am still the person who knows how most of it fits together.

In practice that means: when I am away, decisions wait. When something breaks at night, people message me. For a long time that felt fine. By now it is simply a risk, and it is written down as one. So this is not about taking work off my plate — I want to hand over the job itself.

What you also get is four years of my decisions, a fair number of which were wrong, plus a founder who has to learn to let go while everyone is watching. I would rather write that down now than find out in month three that neither of us meant it.

Daniel Salimian, founder

How to apply

Five steps. No CV needed to start.

1The gate. Three trade-offs and one question about the last thing you shipped.5 min
2The first round. Four real problems from this company. Use whatever tools you would use on the job, including AI.30 min
3A conversation with me. No panel, no competency framework. What you wrote, and whether you actually want this.90 min
4A working session. You, our engineers, and a real problem in our own codebase. They get a say.Half a day
5Founders and references. The other founders, the commercial and operations leads, and references on how you have handled authority before.1 week

A person reads every submission. We do not use AI to score or reject candidates, only to help summarise what you wrote. Your answers are stored in the EU, used only for this vacancy, and deleted after 60 days. Ask us to delete them sooner at any point and we will. You will hear back within one day either way, from a person, and with a reason.

Apply

The first round.

Two stages. The first takes five minutes and everyone does it. If the answers are good, the second one opens immediately. No scheduling, and no waiting a week to hear back.

Stage one · the gate Stage two · the round Done

Not started

Gate 01 · Priorities A senior engineer wants three weeks to rebuild the quote engine properly. Sales wants a feature that unblocks a €400k account this quarter. You have one engineer free.

Rebuild the quote engine. The feature waits. Ship the feature. The rebuild goes on the roadmap. Neither as stated. I would change the shape of the problem first.

In one line, why

Gate 02 · The factory Your operations lead has built herself a tool with AI that saves her team six hours a week. It works. It queries the production database directly. You find out on a Thursday.

Turn it off today, then decide what to do about it. Leave it running, put a guardrail around it this week, own it properly next sprint. Leave it running and have an engineer rebuild it properly. It depends on what “queries” means, and that is the first thing I would find out.

In one line, why

Gate 03 · Your hands You are 30–50% hands-on. In a completely normal week, what do you personally write?

The hardest feature on the board. The thing nobody else can finish. The shared foundations: the tooling, agents and paved paths that everyone else builds on. Whatever is blocking somebody today. Mostly nothing. I review, I do not author.

In one line, why

Gate 04 · The only hard requirement The last thing you shipped to production. When, what, and a link if there is one. This is the one gate that a strong answer elsewhere cannot compensate for. A pull request, a repository, a live product or a paragraph are all fine. “I set the technical direction” is not.

0 / 900

Link, if it is public (optional)

Four answers. Nothing else needed yet. No CV and no cover letter.

Stage one complete

That is the gate. Stage two is open.

Four real problems from this company, about thirty minutes. Two of them come with real output from our own systems. There is no timer and nobody is watching. Use whatever tools you would use on the job, including AI. If you want credit for how you used them, paste your prompts. We are hiring someone to build AI infrastructure for the whole company. Watching you pretend not to use it would tell us nothing.

You can also stop here and we will still read what you wrote. But stage two is what we make the decision on.

01 · Product judgment Three things are on the table. Pick one to do first, and name the one you would kill outright. A. Automated artwork checking. We sign around 115 orders a week and nearly every one carries artwork that a person checks by hand. Removes most of that, and cuts reprints. Hard, rendering-heavy, six weeks minimum.
B. Self-service reordering for our top 200 accounts. Meaningful revenue, meaningful conversion lift, three weeks, low technical risk.
C. Rebuilding the quote pricing model. Nobody trusts the current numbers, so every quote gets a manual sanity check. Unclear scope, high value, touches everything.

0 / 1800

02 · Hands-on This is the real first-90-days output of our shipping rate estimation engine. It is live. On Monday it is yours.

rate.engine · confidence of estimatestrailing 90 days · all sale order transfers

Group	Share	Basis	State
Validated against realised cost	61%	within 90% of the rate we were actually charged	confident
Under 10 kg, not validated	31%	30-day heuristic, expires	confident*
Everything else	8%	logistics must confirm by hand	not confident

* Worst measured cell: Constructed · 5–10 kg · World, at 43% accuracy against realised cost.
Several cells score above 90% but on fewer than 30 shipments, so they do not qualify.
When the 30-day heuristic ends, the 31% row falls back to measured data.

This is real output, not a puzzle we invented. Be specific about three things: what you do in the first two weeks, what you stop or remove, and which part you would build yourself instead of handing to someone else.

0 / 3000

03 · Leverage That same operations lead now wants to build the artwork checker herself, with AI. Do you let her? What has to be true first? The software factory section above describes our three contribution tiers. Tell us where this lands, what you would have to put in place before saying yes, and how you would know a year later whether the model was working.

0 / 2400

04 · The one that matters most It is month five. I pushed a fix straight to production last night, outside your release process. It works, and it fixed a real customer problem. Your team found out this morning, and they are watching what you do. Two answers please: what you do in the next hour, and what you do over the next month. Be specific about what you say to me.

0 / 2400

05 · Optional If you used AI on any of this, paste the prompts. Optional, and to your advantage. How someone directs a model is one of the more useful things we can look at.

0 / 4000

06 · So we can reach you That is the gate sent. We just need somewhere to reply.

Name

LinkedIn, GitHub or a site

Anything you want to ask us

Nothing is sent until you press this. Until then your answers stay in this browser.

Received

Thank you. This is with me, and I read them myself.

You will hear back within one day either way, from a person, and with a reason. You spent real time on this, so here are our own answers to the same questions.

On the €400k feature versus the rebuildUsually we ship the feature and take the debt. But only after the cost of that debt is written down and visible to the management team. Picking the wrong one is not really the problem. Picking silently is.

On the ops lead’s toolIt stays running. That tool is exactly what we want to happen. It becomes tier two by Friday: a named technical owner, a review, tests and a real deployment path. Switching it off would teach everyone else in the building the wrong lesson, and that cost is much higher than the tool.

On what the leader personally writesFoundations. The most valuable code this person writes is code that raises the output of everyone else. Becoming the overflow developer for tickets that nobody owns is the specific failure mode we are trying to avoid.

On me pushing to productionThere is no clever answer here. Tell me directly, tell the team that you told me, and put the fix through the process afterwards. If someone cannot do that in month five, then the handover was never real. That is why the question is on the form.

Prefer to skip this and email me instead? daniel@mondaymerch.com. It is a slower route and I will ask you the same questions eventually, but the door is open.