Business Plan — Pre-Submission Summary
Prepared for facilitator review ahead of a Dutch start-up residence permit application (RVO / IND). This document follows the eight required components and is written to be extended into the full submission without restructuring.
Product & Service Description
What we offer, the problem it solves, and why it is innovative.
Primedge builds AI-native consumer and business software that removes everyday friction in Dutch life for people the existing tools were never designed for — starting with ZZPro, an admin app for self-employed workers, and SmartPark, an automatic parking-session app. Both run on the same core capability: AI-driven workflow automation, a near-zero-cost multilingual layer, and interfaces built for low digital skill. The entire technical and commercial focus of year one is ZZPro; it is the only revenue-generating product. SmartPark is validated in the field through a limited closed beta in month 11 and is not commercialised. A third idea — a Dutch pronunciation app — is a roadmap item to be considered from month 16 onwards and forms no part of this plan's targets.
The problem
The Netherlands has approximately 1.2 million zzp'ers (self-employed without personnel). A large share of them do not do their own admin. In practice their working week looks like this: hours are sent to a client or a bookkeeper (boekhouder) by WhatsApp or e-mail, an invoice is issued on their behalf by someone else, fuel and meal receipts accumulate in a bag and are largely lost, VAT position is unknown until the filing deadline, and nobody tracks which invoice has actually been paid.
The result is a structural one: high error rate, low control, zero personal auditability. The person at the centre of it has no live picture of their own business.
This is not only a language problem. Three distinct groups hit the same wall:
On the founder's most recent project, of 25 people in the same team only two issued their own invoices and filed their own VAT return. The remaining 23 sent their hours to a bookkeeper and never saw the invoice issued in their name. This plan starts from lived experience, not from desk research.
Why now
From 1 January 2025 the Belastingdienst resumed enforcement against false self-employment (schijnzelfstandigheid), and from 1 January 2026 back taxes and penalties apply. In the first half of 2025 alone, 59,000 zzp'ers moved into salaried employment. The zzp population is shrinking — but the zzp'ers who remain now have to be able to demonstrate their independence: their own invoicing, multiple clients, their own records. ZZPro is precisely the instrument that makes that possible for someone who cannot do it unaided.
The product
ZZPro is a mobile-first application that closes the full administrative loop for a zzp'er, in their own language, without ever exposing an accounting concept. The design target is under five minutes of total use per week.
One dataset, three permissioned views
The zzp'er owns the data. The company and the bookkeeping practice see only what the user has authorised, and that authorisation can be withdrawn at any time. This is what lets one dataset serve three parties without any of them losing control.
Prototype — already built
The screens below are operational in the current prototype. They are the strongest evidence that this venture is past the idea stage.
The language layer in operation — same product, same data, Turkish interface
These two screens have the same structure as the Dutch screens above and are taken from the same prototype. Language coverage is a configuration change, not a separate build.
Rendered from the running prototype. The employer portal, in development for Q2, is the one major screen not yet built.
What makes it innovative
Innovation here is not a new accounting engine. It is a control layer designed for the person who cannot use the existing ones. Three concrete mechanisms:
- An AI-native language layer. In conventional software each additional language means a translation agency, a terminology glossary, test cycles and permanent maintenance — which is why almost every Dutch competitor ships in Dutch only. Our interface strings, error messages, help content and document output are generated and verified through a model layer, so the marginal cost of an additional language approaches zero. Ten languages ship at launch, and further languages are added on request rather than on a release cycle. This is not a feature; it is the economic basis of the business — it lets us serve segments no competitor can profitably reach.
- Workflow inversion. Every competitor starts from the ledger: categories, grootboek, VAT codes. ZZPro starts from the hour. Hours become an invoice, the invoice becomes a receivable, receipts become expenses, and the VAT position assembles itself in the background. The user never meets an accounting term.
- Zero-keystroke data entry. Receipts enter the books as photographs, not as typed rows. For a user with limited digital skills this is the difference between using the product and abandoning it.
A fourth mechanism sits at the organisational level and is described in Components 2 and 3: the product is built so that every party in the chain gains from the same data. The zzp'er gets control, the bookkeeping practice gets structured input instead of a carrier bag of receipts, and the company dispatching the work gets one panel instead of thirty conversations. Nobody is displaced, which is why the bookkeeping profession becomes our distribution channel rather than an obstacle to it.
Market Research
Target market, competition, and where our advantage actually lies.
Market size
| Layer | Size | Basis |
|---|---|---|
| TAM — zzp'ers whose main job is self-employment | 1,200,000 | CBS, 2025 annual average |
| Registered zzp businesses in the trade register | 1,805,194 | KVK ZZP Monitor, Q2 2026 — includes part-time and secondary activity |
| Service-providing zzp'ers ("eigen arbeid") | 1,004,000 | CBS, Q4 2025 |
| zzp'ers still working in Excel or on paper | ~440,000 | 37% share, Boekhouder.nl 2024 |
| SAM — intersection of language barrier, age 55+, and low digital skill | 250,000–350,000 | Our own derivation; CBS does not publish this cross-section |
| SOM — realistic year-one capture | 1,200 paying users 20 company accounts | Bottom-up model, Component 5 |
The natural entry base is the labour-migrant population, where self-employment is concentrated and the language barrier is sharpest: 221,650 Polish, 70,110 Romanian and 38,390 Bulgarian workers in the Netherlands (2023), plus roughly 470,000 residents of Turkish origin. Self-employment among EU migrants rose from 5.7% (2007) to 8.6% (2022), and 42% of EU-born self-employed work in construction — the exact profile our prototype was built around.
Competition — an honest reading
A multilingual invoicing product for zzp'ers already exists in the Netherlands. eFaktura.nl, founded in 2017, ships in ten languages and reports 28,000–30,000 users, reaching roughly half of all Polish zzp'ers in the country — built without outside investment. heyzzp offers English, Dutch and Polish.
We treat this as validation rather than as an obstacle. A single-language-family product with no funding reached 30,000 users; the demand question is answered. The relevant question is what it does not cover.
| Product | Entry price / month | Interface languages | Receipt OCR | Client hour approval | Bookkeeper access | Sold to |
|---|---|---|---|---|---|---|
| eFaktura.nl | €11.99 | 10 in-app | Pro tier (€24.99) | None | Yes, on every tier | Multilingual zzp'ers |
| Freeliq | €12.00 | NL + EN | Not documented | Yes — client signs off from an e-mail link | Yes, on the paid tier | zzp'ers |
| Moneybird | €15.00 | NL + EN | Yes | None | Yes — "Mijn kantoor"; the client grants access | zzp / mkb |
| e-Boekhouden.nl | €9.95 | Dutch only | Yes, per-document fee | None | Yes | zzp / mkb |
| Rompslomp | €7.95 | Dutch only | Yes | None | Yes | zzp'ers |
| Tellow | €12.99 | Dutch only | Yes | None | Yes | zzp'ers |
| SnelStart | €15.50 Accountant €49.50 | Dutch only | Yes | None | Yes — Accountancy Dashboard | zzp / mkb + practices |
| Jortt | €19.95 | NL + EN | Partial | None | Yes | zzp / mkb |
| onlineUUR (ZZPsupport) | Not published | Dutch only | None | Yes | None | Uitzendbureaus / intermediaries |
| Flexwell | €240 + €2,000 setup | Dutch only | None | Yes + self-billing | API only | zzp-bemiddelaars / uitzendbureaus |
| ZZPro | €5.00 | 10 at launch | Yes, on every tier | Yes — direct, no intermediary | Yes, permission-based | zzp + client company + bookkeeper |
Prices and features are taken from each vendor's own published pages (August 2026). The table is deliberately built to be honest against us: bookkeeper access is standard in this market, and client hour approval also exists — but in two separate worlds.
Every feature in that table already exists separately in the Dutch market. We write this plainly because it is true and easily checked. The market is split into two worlds:
On one side, zzp bookkeeping products. Moneybird, e-Boekhouden, Tellow, Rompslomp, SnelStart, Jortt, eFaktura — all offer bookkeeper access, most offer receipt OCR. None has a flow in which the client company approves hours. Freeliq is the exception: it solves client sign-off through an e-mail link, but in two languages and from €12.
On the other side, intermediary software. onlineUUR and Flexwell do offer client hour approval and automatic invoicing, and even self-billing. But they are sold to uitzendbureaus and zzp-bemiddelaars; there the zzp'er is a user of a portal the intermediary provides, not the owner of their own records. Flexwell starts at €2,000 setup plus €240 a month.
The gap sits precisely here: no product lets the zzp'er remain the owner of their own records, with the client approving directly and without an intermediary, and the bookkeeper reaching only what has been authorised — in ten languages, with receipt OCR, at €5 a month. The components exist; this combination does not.
What we are actually replacing
The alternative to ZZPro is not another product. For the segment we serve it is no system at all — hours sent by WhatsApp, receipts in a bag, a spreadsheet if anything. That is what 37% of Dutch zzp'ers still work with, and it is the status quo we compete against.
The bookkeeper is explicitly not in that category. A Dutch bookkeeping practice charging €80–150 a month is doing real work for it: filing the VAT return, issuing weekly invoices from the client's hours, booking every expense line by line. ZZPro does not take that work away — it removes the part of it that is pure friction. When the hours arrive already structured, the expenses already coded and the VAT position already assembled in the return's own boxes, the practice spends its time on advice and filing rather than on chasing a client for a fuel receipt.
This is the most important commercial insight in the plan. A bookkeeping practice with fifty zzp clients that recommends ZZPro and helps them set it up delivers fifty users in a single conversation — and does so because it is in the practice's own interest, not as a favour.
The product supports both directions. With the client's consent, the practice can pull everything it needs from its own bookkeeper view. Without that consent — or where the client prefers to stay in control — the zzp'er simply uses the app alone and still sends a clean, complete export. Every party gains at every step: the zzp'er gets visibility, the practice gets structured data, and the company that dispatches the work gets one panel instead of thirty WhatsApp threads.
Competitive advantage, summarised
- Language economics. Near-zero marginal cost per language. eFaktura took eight years to reach ten languages; we are on a different cost curve.
- Distribution from inside the segment. The founders come from the target population and already hold the network. Acquisition starts as conversation, not as paid advertising.
- Two batch channels nobody else has. One company contract connects thirty users; one bookkeeping practice can connect fifty. Both parties adopt us out of self-interest, so acquisition cost is close to zero and no competitor can match it.
- Build speed. Our own AI agent development stack lets a two-person company carry a product scope that conventionally requires six to eight people. This is why the budget in Component 5 is as small as it is.
Marketing & Sales Strategy
How we reach the audience and convert it into revenue.
Pricing
| Offer | Price | Rationale |
|---|---|---|
| Individual — 30-day trial | Free | All features open, no card required. The user must see a finished invoice before being asked to pay. |
| Individual — full product | €5 / month | One tier, every feature. Splitting features fails here: expense tracking without OCR and invoicing without the VAT panel are each half a product. Our audience also does not want to choose a plan. |
| Individual — annual | €50 / year | Two months free; pulls cash forward. |
| Company account | €149 / month + €4 per connected zzp'er | A firm with 25 zzp'ers pays €249/month — far below the cost of the administrative time it replaces. Connected zzp'ers may use the individual product free while the company pays. |
| Large company — Enterprise | From €499 / month | For firms dispatching 75 or more zzp'ers: multi-entity structure, project and cost-centre hierarchy, bulk approval, custom reporting and export, dedicated onboarding and priority support. Priced per organisation rather than per seat, because at that scale the value is the administrative headcount it displaces. |
| Bookkeeping practice | Free in year one | Portfolio view with client consent. No charge while practices are our primary acquisition channel; a commercial tier is designed only after roughly 10,000 users. |
€5 is deliberate penetration pricing. In year one we are buying a user base and corporate references, not margin.
The company channel — the core of the go-to-market
Consider a painting contractor running projects at several sites and dispatching the work to thirty zzp'ers. Today it collects hour reports and invoices from each of them individually, over WhatsApp, e-mail and paper. On the company side this is close to a full-time administrative job.
The ZZPro Employer Portal gives that company one panel: it sees and approves the hours its zzp'ers enter, receives the invoices issued in each zzp'er's own name as a single batch, produces cost reporting per project and location, and sends one file to its own accountant.
We do not launch by publishing to the app stores and waiting for users. In months 2–3 we meet five to ten companies from the founders' existing network and sign two to three as design partners: they shape the employer portal with us and run the closed beta with their own zzp'ers.
This produces three things at once — product-market fit proven before launch, revenue contracted from month 3, and the letters of intent the permit transition requires already in hand rather than chased in month 11.
Channel plan
| Phase | Channel | Cost |
|---|---|---|
| Months 1–4 | Direct meetings with companies from the founders' network; design-partner agreements; closed beta with their zzp'ers | None — founder time |
| Months 5–8 | Community outreach in Turkish, Polish, Bulgarian and Romanian zzp groups; uitzendbureaus and intermediaries (20–40 zzp'ers per contact); partnerships with small bookkeeping practices; short-form video in the user's own language | Low |
| Months 9–12 | Referral programme; targeted paid advertising — only after unit economics are proven; sector associations and KVK events | €3,000 budget |
The bookkeeper channel
A practice does not adopt ZZPro because we ask it to; it adopts it because a client who arrives with structured data costs it less time than one who arrives with a carrier bag. That makes the referral arrangement natural rather than negotiated, and it means acquisition happens in batches rather than one user at a time.
We target six practices across the year on a discount-code model, the first two in Q2. A single practice with fifty zzp clients converts, at even 50% adoption, into a fifth of our year target. The 1,200-user figure in Component 5 assumes this channel works in only half of the six practices.
The bookkeeper view is a first-class part of the product, not an export button: with the client's consent a practice sees its clients' hours, invoices, expenses and quarterly VAT position from its own login.
We charge bookkeeping practices nothing in year one, and Component 5 carries no bookkeeper revenue line. Practices are the backbone of both user acquisition and data quality; charging them at the exact point where we need them to recommend us would trade a distribution channel for a rounding error.
A practice subscription becomes a question only once the installed base passes roughly 10,000 users. At that point the portfolio view carries enough value that a commercial tier can be designed from pilot evidence rather than from assumption.
Targets
| Metric | Month 3 | Month 6 | Month 9 | Month 12 |
|---|---|---|---|---|
| Company accounts | 2 (unpaid pilot) | 4 | 11 | 20 |
| Bookkeeping practice partnerships | 0 | 2 | 4 | 6 |
| Registered users | 120 | 700 | 2,000 | 4,500 |
| Paying individual users | 0 | 140 | 500 | 1,200 |
| Free users covered by a company account | 0 | 90 | 260 | 600 |
| Monthly churn target | — | <8% | <6% | <5% |
Operational Plan
Legal structure, staffing, resources and how the company runs day to day.
Legal structure
Primedge B.V., Rotterdam, incorporated 24 June 2025, registered with the KVK. Two statutory directors (algemeen directeur), both resident in the Netherlands with valid residence status.
SBI classification
The Netherlands replaced SBI 2008 with SBI 2025 in the Handelsregister on 6 September 2025 and converted existing registrations automatically. We will verify and align our registration before submission:
| Role | Code | Official description | Reason |
|---|---|---|---|
| Main activity | 62.10.0 | Ontwerpen van computerprogramma's | The only code in the classification that explicitly covers the development of AI and machine-learning applications. It also aligns with the WBSO software-development track. |
| Secondary | 58.29.0 | Uitgeven van overige software | Publishing our own subscription applications through the app stores. |
| Secondary | 62.20.0 | Computerconsultancy en beheer van computerfaciliteiten | AI advisory and integration work delivered to client companies. |
Changes are filed free of charge through Mijn KVK; reordering activities requires Formulier 18. Note that KVK derives the code from a free-text activity description, so the description will lead with development language rather than publishing or advertising terminology. The classification also affects bank onboarding, insurance cover and subsidy eligibility, which is why we treat it as a submission item rather than an afterthought.
VAT and data protection
- VAT. Subscriptions sold through the App Store and Google Play are handled with the platform as merchant of record, which removes the OSS registration question for that channel. Company accounts are invoiced as ordinary Dutch B2B transactions with BTW. Confirmed with our accountant.
- AVG / GDPR. The application processes financial data. Within year one we establish a processing register (verwerkingsregister), a retention and deletion policy, EU-region hosting, and a verwerkersovereenkomst template for company accounts.
Day-to-day operations
| Function | How it runs | Owner |
|---|---|---|
| Product development | In-house AI agent development stack; weekly release cycle | M.B. Oymak |
| Customer support | In-app chat plus a WhatsApp line, in the user's own language | A.Z. Oymak |
| Company sales & account management | Direct meetings, design-partner model, onboarding and retention | A.Z. Oymak |
| Individual acquisition | Community outreach, content, referral programme | Shared |
| Finance & administration | External bookkeeping practice; monthly close; supplier and contract coordination | A.Z. Oymak |
| Mentoring | Intensive programme with the facilitator in the first three months, monthly progress reporting thereafter | Both |
Resources
Cloud hosting in the EU region, database and file storage; AI and OCR model API usage; transactional e-mail; payment infrastructure (iDEAL, SEPA, card); Apple and Google developer accounts; error monitoring; design and development tooling. No fixed office cost in year one — remote working plus flexible workspace.
Staffing
Year one: two founders full-time, no employees. From month 9, if retention and growth targets hold, a part-time multilingual customer-support role is added. This is stated in the plan as conditional rather than assumed.
Financial Planning
Budget, revenue projection and funding strategy — built bottom-up, with every line traceable to a unit and a price.
Every revenue line below is derived month by month from a user count or a contract count multiplied by a published price. Consulting revenue is limited to a small number of scoped engagements and accounts for 16% of year-one revenue, falling to 6% of the month-12 run-rate. The subscription and company-account legs carry the business.
Revenue build-up
Leg 1 — Individual subscriptions (€5/month)
| Quarter | Paying users, end of month | Paid user-months | Revenue |
|---|---|---|---|
| Q1 — months 1–3 | 0 (closed beta) | 0 | €0 |
| Q2 — months 4–6 | 40 / 80 / 140 | 260 | €1,300 |
| Q3 — months 7–9 | 230 / 350 / 500 | 1,080 | €5,400 |
| Q4 — months 10–12 | 700 / 930 / 1,200 | 2,830 | €14,150 |
| Year 1 | 1,200 at month 12 | 4,170 | €20,850 |
For scale: eFaktura.nl reached roughly 30,000 users over eight years without funding, focused on one language family and with no batch distribution channel. 1,200 paying users in year one — with three channels running in parallel (bookkeeping practices, company accounts, community) — is a conservative fraction of that trajectory.
Leg 2 — Company accounts (€149 base + €4 per connected zzp'er)
| Quarter | Paying companies, end of month | Company-months | Avg. / month | Revenue |
|---|---|---|---|---|
| Q1 | 0 — 2 unpaid design partners | 0 | — | €0 |
| Q2 | 1 / 2 / 4 | 7 | €200* | €1,400 |
| Q3 | 6 / 8 / 11 | 25 | €249 | €6,225 |
| Q4 | 14 / 17 / 20 | 51 | €249 | €12,699 |
| Year 1 | 20 at month 12 | 83 | — | €20,324 |
* Launch discount for early accounts. €249 is a company connecting 25 zzp'ers. Twenty company accounts over twelve months means roughly two signatures per month from month 4 onward. With a founder working the commercial side full-time on an existing network, this is the most controllable number in the plan.
Leg 3 — AI automation services (deliberately minor)
Two scoped engagements plus small maintenance retainers, sold to the same companies already at the table for the employer portal. Each is a defined deliverable, not an aspiration:
| Engagement | Deliverable | Price | When |
|---|---|---|---|
| AI content engine | Brand-tone social and web advertising content generation with a monthly content calendar | €2,500 setup €250/mo | Q1 |
| Recruitment assistant | Vacancy text generation, application pre-screening, 24/7 candidate Q&A, interview scheduling | €2,500 setup €250/mo | Q2 |
| Maintenance retainers | Ongoing operation of the above for up to 3 clients | €250/mo each | Q3–Q4 |
| Year 1 total | €8,000 |
Consolidated revenue projection
The product legs carry the business. Consulting is a bridge in the early quarters and shrinks to a minor share by Q4.
| Revenue line | Q1 | Q2 | Q3 | Q4 | Year 1 | Share |
|---|---|---|---|---|---|---|
| Individual subscriptions | €0 | €1,300 | €5,400 | €14,150 | €20,850 | 42% |
| Company accounts | €0 | €1,400 | €6,225 | €12,699 | €20,324 | 41% |
| AI services | €2,500 | €2,500 | €1,000 | €2,000 | €8,000 | 16% |
| Total | €2,500 | €5,200 | €12,625 | €28,849 | €49,174 | 100% |
Cost budget
| Line | Year 1 |
|---|---|
| Cloud hosting, database, storage | €2,400 |
| AI and OCR model API usage | €3,600 |
| App store commission and payment fees | €1,800 |
| Software tooling, licences, developer accounts | €1,400 |
| Marketing (from Q3) | €4,500 |
| Accounting, legal, GDPR advisory | €3,000 |
| KVK, insurance, banking | €1,000 |
| Travel, field sales, events | €1,200 |
| Part-time multilingual customer support (months 10–12) | €2,700 |
| SmartPark closed beta infrastructure Incremental only — runs on ZZPro's existing stack | €600 |
| External technical validation and security audit Production architecture review, code audit and penetration test by an independent senior developer / security specialist — Q2–Q3 | €6,000 |
| Operating subtotal | €27,200 |
| Facilitator programme fee (2 × €6,000, spread over 12 months) | €12,000 |
| Total year-1 cost | €39,200 |
The weight of this budget sits on a single commercial product; SmartPark appears only as the incremental cost of a closed beta. The budget is small because the development model is small: our AI agent stack lets two people carry a scope that conventionally requires a team of six to eight. The known weakness of that model — production-grade architecture and security review — is met by an explicit line in the budget: €6,000 of external technical validation, carried out by an independent specialist in Q2–Q3, whose report is submitted to the facilitator review.
Year-one result
| Measure | Value |
|---|---|
| Year-1 revenue | €49,174 |
| Year-1 cost | €39,200 |
| Year-1 operating result | +€9,974 |
| Month-12 monthly recurring revenue 1,200 × €5 + 20 × €249 + 3 × €250 | €11,730 |
| Month-12 monthly cost run-rate | €3,400 |
| Month-12 monthly operating profit run-rate | €8,330 |
| Of which one-off spend External technical validation, incurred once in the year | €6,000 |
Year one closes positive, and the company enters month 12 on a recurring revenue base that matters more than the annual total: 83% of revenue comes from subscriptions and company accounts — lines that repeat.
Year 2 outlook
| Line | Month 24 | Year-2 revenue |
|---|---|---|
| Individual subscriptions | 3,000 paying users | €126,000 |
| Company accounts | 45 companies | €95,600 |
| AI services | 5 retainers | €18,000 |
| Cost base incl. two part-time hires | −€110,000 | |
| Year-2 result | ≈ €129,600 · €10,800/month |
By month 24 the company reaches an operating profit that supports both founders and two part-time staff. SmartPark and the pronunciation app, released as free betas in year one, are monetised in this period; their revenue is not included in the figures above.
Capital requirement
The company is structured to need no external capital. Year-one operating cost is met from revenue generated from Q1 onward, and because product development runs on our own AI agent stack there is no capital-intensive line to fund.
| Requirement | How it is covered |
|---|---|
| Operating cost, €27,200 | Company revenue from Q1 onward; by Q3 monthly costs are fully met by monthly revenue. |
| Product development | Founder labour and the in-house AI agent stack; no external development spend. |
| Cash buffer | Q1–Q2 service revenue and the annual payment option on company accounts pull cash forward. |
Part of the technical work — the architecture of the language layer and the accuracy engineering behind receipt extraction — may qualify under RVO's WBSO scheme as programmatuurontwikkeling. WBSO supports software development that is technically new to the company and carries genuine technical uncertainty; the starter rate is 50% on the first €380,000. Connecting an existing API does not qualify, and we do not claim it does. We intend to have the scope assessed by a WBSO adviser during year one.
Team & Roles
Organisational structure and the concrete daily responsibilities of each founder.
Primedge B.V. has two statutory directors. The division below is not a formality — it separates the company cleanly into a build function and a market function, so that each founder holds an independently demonstrable active role.
- Product definition, roadmap and release management
- AI agent development stack; the multilingual layer architecture
- OCR / receipt extraction accuracy engineering
- Employer portal design and build
- Technical delivery of AI automation engagements
- Data protection and security implementation
- Weekly release cycle
- Direct user-feedback sessions with beta users
- Technical scoping with design-partner companies
- Worked as a zzp'er in the target segment; the problem definition originates from his own working weeks
- Built the existing working prototype end to end — product architecture, data model, language layer and document extraction pipeline included
- His working method is AI-assisted product development and technical orchestration: architecture and product decisions rest with the founder, the bulk of code generation with the agent pipeline he built and directs
- Company account acquisition: outreach, meetings, contracts
- Design-partner relationships and letters of intent
- Customer relations and multilingual support line
- Bookkeeper and uitzendbureau partnership programme
- Finance and administration: bookkeeping coordination, monthly close, supplier contracts, insurance, KVK filings
- Facilitator reporting and milestone documentation
- Company meetings and pipeline management
- Onboarding and retention calls with active accounts
- Monthly financial close with the external practice
- Management and coordination background; holds the commercial network the company channel depends on
Both founders work full-time on the venture and are resident in the Netherlands with valid residence status. Neither holds a passive investor role: each owns delivery of a distinct half of the operating plan in Component 7, and the milestone table names the responsible founder for every activity.
Technical annex — how the prototype was built
We set this out explicitly because the team is two people and the scope delivered is unusual for a team of that size. An assessor needs to be able to check it.
| Question | Answer |
|---|---|
| Who built the prototype | Muhammet Bahadır Oymak, alone. No external agency, freelance developer or off-the-shelf white-label product was used. |
| How it was built | An AI-assisted development pipeline: the founder defines the product architecture, data model and interface flows; the bulk of code generation is carried out by the chain of AI coder agents he built and directs; every output is reviewed and integrated by the founder. This is the sole explanation for the speed and cost structure in this plan. |
| What works today | Authentication and a multi-user data model; hour registration; invoice generation and e-mail dispatch; expense and receipt upload; AI receipt reading; mapping of the VAT summary onto the boxes of the Dutch VAT return; the multilingual interface layer. |
| What is not yet production-grade | The permission model of the employer portal (Q2), payment infrastructure (Q2), OCR accuracy calibration at scale, security hardening and load testing. |
| What "our own infrastructure" means | Two layers: (1) the language layer — a controlled glossary for financial and administrative terminology, shared by all products and not left to a general-purpose translation service; (2) the document extraction pipeline — the measured chain running from a receipt or invoice image to structured fields and on into the VAT-return boxes. Both layers are shared by ZZPro, SmartPark and the pronunciation idea on the roadmap. |
| Independent validation | An architecture review, code audit and penetration test by an independent senior developer / security specialist in Q2–Q3, budgeted at €6,000 in Component 5. The report is submitted to the facilitator review. |
The risk of this approach is not hidden: AI-assisted development is fast, but production-grade architectural resilience and security require independent review. That is why the audit is a budgeted line rather than an intention.
Step-by-Step Development Plan — First Year
Activities and milestones month by month, with the responsible founder named. This section exists to demonstrate the entrepreneurs' active operational role.
- M1 Facilitation agreement signed, mentoring starts; KVK activity description and SBI alignment; GDPR framework; product requirements document (both)
- M2 Prototype moved to production architecture — authentication, data model, multilingual infrastructure (MBO); meetings with 5–10 companies (AZO)
- M3 Hours, invoicing and e-mail dispatch hardened for production (MBO); first AI automation engagement delivered and invoiced (both)
- M4 Expense module and AI receipt scanner to production accuracy; payment reminder engine (MBO)
- M5 VAT panel and bookkeeper export finalised; iDEAL/SEPA payment infrastructure; facilitator three-month assessment (both)
- M6 Employer portal v1 built with design partners (MBO); paid subscriptions open; first company accounts converted to paying (AZO)
- M7 Language coverage extended beyond the launch set on request; own-language content production begins (MBO)
- M8 Uitzendbureau and intermediary channels; a total of 4 bookkeeping practices signed to the partner programme; recruitment assistant packaged as a product (AZO)
- M9 Unit economics analysis — CAC, LTV, churn; first paid advertising test (both); SmartPark beta build starts on the shared stack (MBO)
- M10 Scaling across advertising, referral and channel; retention programme to bring churn below 5% (both)
- M11 Transition file assembled — profit documentation, 4–5 letters of intent, accountant's statement (bijlage 7112) (AZO); SmartPark closed beta goes into the field with 50–100 invited drivers — no revenue target, the purpose is validation of detection accuracy (MBO)
- M12 Year close; findings of the external technical validation report closed out (MBO); year-2 plan and monetisation design for SmartPark (both)
Innovation
RVO requires at least one of the three criteria set out in Bijlage 8b. This venture answers all three; its centre of gravity is criteria 3 and 1.
This is our principal claim. In the Netherlands the zzp'er – client company – bookkeeping practice triangle runs today over WhatsApp, e-mail and paper, and the same data is entered three times: the zzp'er reports hours, the company transfers them into its own spreadsheet, the practice reorganises the documents arriving from both. All three repeat the same work and none of them can verify the others' record.
ZZPro restructures that division of labour: one dataset, opened to three parties through role-based and revocable permission. The data is created in the zzp'er's account and stays in their ownership; the company sees and approves only hours and invoice data relating to its own projects; the practice reaches only the period data its client has authorised. Nobody enters the data a second time and everyone works from the same record.
This is not a software feature but a change in the permission and ownership model. In the market today, client approval exists only in intermediary software — and there the data sits in the intermediary's system; bookkeeper access exists only in bookkeeping products — and there the client side is absent entirely. ZZPro brings all three parties into one system with the zzp'er as the owner of the data.
We keep this claim deliberately narrow and checkable. We do not claim that multilingual invoicing is new for the Netherlands — eFaktura.nl occupies that ground, and we say so plainly in Component 2. Our claim is this:
"Bookkeeper access and client hour approval both exist separately in the Dutch market. But the three-sided arrangement in which the zzp'er remains the owner of their own records, the client approves — without any intermediary — only the hours and invoices of its own projects, and the bookkeeper reaches only the financial data released to them, combined in one product in ten languages, with receipt recognition and for €5 a month, does not exist."
"Toegang voor de boekhouder en urenaccordering door de opdrachtgever bestaan afzonderlijk op de Nederlandse markt. De combinatie waarin de zzp'er eigenaar blijft van zijn eigen administratie, de opdrachtgever zonder tussenpersoon uitsluitend de uren en facturen van zijn eigen projecten accordeert, en de boekhouder alleen toegang heeft tot de daartoe vrijgegeven financiële gegevens — in tien talen, met bonherkenning en voor €5 per maand — bestaat niet in één product."
The nature of the novelty matters here: we do not claim to have invented portals. Our claim is that parts which today sit in separate products and separate price classes are combined into one product, under a different permission and ownership model, for a population that is not served. RVO's own list of examples counts "slimme en creatieve aanpassingen of combinaties" and "nieuwe product-markt combinaties" as indicators of innovation.
Two supporting claims accompany it:
A new product-market combination. No bookkeeping or invoicing product for zzp'ers exists in Turkish, Bulgarian or Arabic in the Netherlands — verified by searching in Dutch, English, Turkish, Polish, Romanian and Russian. All three are in our launch set. RVO's own list of examples names "nieuwe product-markt combinaties" as an indicator of innovation.
Social innovation. We serve a population that existing tools structurally exclude: 60% of zzp'ers are aged 45–75, 53% of 55–65-year-olds have at most basic digital skills, and 36% of new entrepreneurs have a migration background. For this group the product is inaccessible not because it is expensive or monolingual, but because it is unusable. RVO's list of examples names "sociale innovatie" explicitly.
We advance this criterion as supporting rather than principal, and we draw its boundary clearly: we do not treat calling a ready-made language-model API as innovation. The innovation lies in the infrastructure we built on top of those models, which all our products share.
Language layer
Not a translation file but a production pipeline: a controlled tax and business terminology glossary (one correct rendering per language for terms such as BTW, voorbelasting, naheffing), model-driven generation followed by automated validation, RTL support for right-to-left scripts, and localisation of invoice and report output alongside interface text. The result: the marginal cost of an additional language approaches zero, and adding one becomes a configuration matter rather than a release.
Document extraction and VAT-box mapping layer
Extracting data from a receipt is not by itself new. Our layer maps the extracted data directly into the boxes of the Belastingdienst's VAT return: VAT on turnover to 1a, deductible VAT to 5b, net payable to 5e. Every intermediate step between photographing a receipt and a line on the return — category selection, rate determination, offsetting, period assignment — is taken away from the user. This is operational in the prototype and visible in the screenshots in Component 1.
Cross-sector application
The same infrastructure serves three different domains of daily life: admin (ZZPro), mobility (SmartPark) and language learning (the pronunciation app). Neither SmartPark nor the pronunciation app requires localisation from scratch or its own extraction pipeline; both inherit Primedge Core. RVO's list of examples names "slimme en creatieve aanpassingen of combinaties voor sector overschrijdende toepassingen" as an indicator of innovation.
Evidence for the innovation claim
Bijlage 8b provides for the innovative character to be shown by "bewijsmiddelen (bijv. patenten of referenties van kennisinstellingen e.d.)". We hold no patent. The evidence below is submitted as annexes to the application.
Attached to the application
To be obtained during year one
What we do not claim
We do not claim to have built a new accounting engine, to have invented multilingual invoicing, or that document extraction technology is itself new. Our innovation claim rests in three places: the organisational model in which three parties work on one permissioned dataset, the employer portal that does not exist in the Netherlands together with the underserved population at the intersection of language, age and digital skill, and the infrastructure of our own that makes both possible. We keep the scope this narrow because each of the three claims can be verified independently.
Focus: one commercial product, one closed beta
The only product commercialised in year one is ZZPro. All technical and commercial resources are committed to it; the employer portal, language coverage and the bookkeeper channel form the milestones of the year.
SmartPark carries no revenue target in year one. In month 11 a closed beta runs in the Randstad with 50–100 invited drivers; its purpose is not revenue but field validation of detection accuracy and of the declared-postcode rule. Because it runs on the same infrastructure, the additional development load is limited, and it has no line at all in the Component 5 revenue projection.
The third idea — a Dutch pronunciation app — falls outside this plan's targets and is noted at the foot of this page as a roadmap item to be considered from month 16.
SmartPark — second product, public beta in month 11
The problem. Paid parking in the Netherlands is entirely licence-plate based and runs through mobile applications. Every driver has to remember two separate actions — start the session on arrival, end it on departure — and routinely fails at one of them. Forgetting to stop is by far the more common and more expensive failure. Every car owner in the country experiences this several times a year.
Concept screens: vehicle and declared permit postcodes, zone map, and an automatically started session. Final interface will be shaped by the beta.
The product. SmartPark removes both actions. The vehicle's own Bluetooth connection is the signal: when the phone connects, the driver is in the car; when it disconnects, the car has been parked. GPS then determines whether that location falls inside a paid zone.
SmartPark does not need to query any municipal or NPR permit register. The user declares their permit postcode areas once in the app — exactly the way they declare their licence plate — and the app suppresses automatic activation inside those areas. Declared data, not queried data. This keeps the architecture simple, keeps the user in control of their own information, and removes any dependency on third-party data access.
Why the gap is open. Genuine phone-based automatic start and stop does not exist as a consumer product in the Netherlands. Flitsmeister is widely assumed to be automatic but is not — its own help documentation states that the parking session is not ended automatically; it detects movement and sends a notification the driver must confirm. True automatic stopping exists only through in-car systems built into specific vehicle brands and through fleet telematics hardware — all requiring installed equipment, all sold B2B. Nothing serves the ordinary driver with an ordinary phone.
Why it fits Primedge. SmartPark reuses the same building blocks as ZZPro: a mobile-first interface designed for people who do not want to learn software, a multilingual layer at near-zero marginal cost, and automation that removes user actions rather than adding features. It also shares the audience — the labour-migrant and low-digital-skill population that drives to work sites daily and pays for parking at every one of them. Distribution can run through the ZZPro user base at no additional acquisition cost.
Safety layer
Automation that acts on a driver's behalf has to be conservative. Four controls are part of the design rather than added later: explicit confirmation on first use and in ambiguous situations; manual override — every session can be started, stopped or corrected by hand; live notification so the session state is always visible; and a fail-safe that caps maximum duration and stops acting when the signal is uncertain.
Closed beta — months 10–12
SmartPark is validated with 50–100 invited drivers in the Randstad before parking-provider coverage is widened. The beta measures detection accuracy, the declared-postcode rule and user trust — not revenue.
Business model. Standalone subscription at €2.99–€4.99 per month, or bundled into a higher ZZPro tier; fleet sales are a second-phase question. The saving is concrete: a single avoided penalty covers more than a year of the product. SmartPark revenue is not included in the year-one projection — the month-12 target is validated beta evidence, not income.
Roadmap note — pronunciation app, from month 16
This is not a year-one target. It belongs to the 24–36 month vision and is mentioned here only to show how far our own language and OCR infrastructure reaches; it appears in no revenue or cost line in Component 5. The idea: enter a Dutch sign, text or word by camera (OCR) or by typing, and hear the correct pronunciation. A single function, no learning curve. The purpose is to remove the largest psychological barrier to learning Dutch — the fear of mispronouncing — for the same migrant population ZZPro already serves.