7 min read
I had a live platform with paying members, fifty-odd people who had moved into employment through it, and university relationships in three countries. And I would have failed at least two of those three gates on the day I read them.
What followed was a fortnight of work that should have taken eighteen months in the background. Every hour of it was work I would have had to do eventually — for a university procurement questionnaire, for a data protection officer, for an investor’s diligence. Doing it all at once, against a deadline, cost more than doing it steadily would have.
So here is the build order I would follow if I started again. It is not a compliance checklist bolted onto product development. It is product development, sequenced properly.
1. Name your buyer before you name your features
The first thing I got wrong was the most expensive, and it had nothing to do with regulation.
I built for students. Students are the users, they have the problem, and they are the reason the thing exists. But students in education do not have budget, and asking a job seeker to pay for access to employment is a place you do not want to be — commercially or legally.
The buyers in this sector are institutions and employers. A university careers service has a budget line. An employer hiring graduates has a cost of getting it wrong. Neither of them is the person using your product every day, and both of them will ask questions your user never will.
That single distinction reorganises everything: what you build, what you charge for, what you keep free, and which questions you have to be able to answer. Work it out on paper before you write code, because retrofitting a business model into a product is far harder than retrofitting a feature.
The rule: write down who pays, who never pays, and what each of them gets — in one paragraph, before you build.
2. Write down where your data lives, before you have any
When I finally sat down to complete our data hosting record, I discovered our published privacy policy stated that user data was held on Amazon Web Services in the EU.
We have never used AWS. The platform runs on a European host, our records sit in Google Workspace under Google’s Irish entity, and payments go through Stripe’s Dublin company. The AWS sentence had been written a year earlier, by someone reaching for a plausible-sounding description of infrastructure that did not yet exist, and it had sat on a live website ever since.
Nobody had lied. Nobody had checked either. And that sentence — one line, in a document nobody reads — was a false statement about data location on the exact question every institutional buyer asks first, and one an examiner can verify independently in about a minute.
Keep a single document from your first week. Every layer of your stack, every provider, what region it sits in, and — if anything sits outside the EEA — the mechanism that makes the transfer lawful. It takes an hour to start and five minutes to update. Starting it eighteen months late means auditing infrastructure you barely remember choosing.
The rule: one hosting and processors record, from day one, updated whenever you add a provider.
3. Describe only what exists
The same policy described an AI assistant that had been “trained on aggregated, anonymised career outcomes”, and an algorithm that generated verified portfolio scores.
Neither exists. Both are on our roadmap, and both had been written up in the present tense in the enthusiasm of an early launch.
That is a common startup habit and normally the cost is embarrassment. Here the cost was nearly serious, because the whole basis of our position under the EU AI Act — the thing that differentiates us, the thing I have argued for in front of academics — is that no AI system makes or recommends a decision about a candidate on our platform. Every assessment is a named human against a published rubric.
Our own website said an algorithm scored people. Anyone reading both documents would have found a flat contradiction, in the place where I had staked most of our credibility.
Roadmap goes in the future tense. Always, everywhere, but especially in documents that describe how you handle people’s data — because a privacy policy is not marketing copy. It is a description of processing that occurs, and describing processing that does not occur is not an overstatement. It is simply wrong.
The rule: if it does not exist today, it is written as “we are building”. No exceptions on legal pages.
4. Decide your AI position early, and in writing
The EU AI Act treats systems used in recruitment and candidate evaluation as high risk. If your EdTech product touches hiring, employability, admissions or progression, that probably includes you.
There is a temptation to describe your matching engine as a “recommendation feature” and hope the question does not come up. It will come up — from a university’s data protection officer, if not from a regulator.
We declare in the high-risk category and describe our controls, and we can do it comfortably because of a decision made early rather than a document written late. AI drafts project briefs and assessment rubrics from an employer’s role description; the employer edits and approves them. No model scores, ranks or rejects a person. There is no video, image or voice analysis. Every assessment carries a named reviewer and written reasoning, and anyone can request human review.
That is slower and more expensive than the alternative. It is also the only version I would defend in a room full of careers advisers.
The point is not that everyone should make the same choice. It is that the choice determines your architecture, so make it before the architecture exists.
The rule: decide what your AI is allowed to decide, before you build the thing that decides.
5. Accessibility is a gate, not a polish task
Of the three pass/fail checks, accessibility is the one most likely to end your submission, and the slowest to fix.
Irish public bodies operate under accessibility obligations, the European Accessibility Act extends comparable duties across the EU, and any university procurement will ask for an accessibility statement. A platform that cannot answer does not reach the evaluation stage, however much the careers service likes it.
The frustrating part is that the common failures are cheap to prevent and tedious to retrofit: colour contrast, missing form labels, absent focus states, keyboard traps, unlabelled images. Caught as you build, each is a few minutes. Found across four completed user journeys two weeks before a deadline, they are days.
Run axe DevTools or Lighthouse over each flow as you finish it. Not at the end. At the end there is no time, and the fixes touch code you have moved on from.
The rule: every flow gets an accessibility pass before it ships, and the statement documents what remains rather than overstating what does not.
6. Start measuring outcomes on day one
The heaviest section of the awards matrix asks for quantitative evidence of impact in Irish learning environments over the past twelve to twenty-four months.
That is not a criterion you can satisfy by deciding to. It requires having tracked real people over real time and being able to show what happened to them. It is the one input nobody can acquire at short notice, and it is exactly what institutional buyers now ask for — outcomes, not engagement. Logins and completion rates tell a careers service nothing. Ten documented destinations beat ten thousand sessions.
We were lucky rather than wise here. We had kept records because the records are our product — the whole model is a verifiable account of what someone did. If you are building anything in employability, skills or progression, keep that record from your first user, with their consent, and be clear that the work belongs to them and not to you.
The rule: decide what outcome you are claiming to produce, and start recording it before you have anyone to record.
The underlying point
Every one of these six is usually filed under compliance, which is why founders defer them. Filed correctly they are product decisions: who pays, what you store, what you claim, what your system is permitted to decide, who can use it, and what you can prove.
Deferred, they become a fortnight of unpaid work at the worst possible moment, and a set of live documents contradicting each other in public.
Done in order, they are the reason an institution can buy from you at all.
I am not writing this as someone who got it right. I am writing it as someone who spent two weeks last month fixing what eighteen months of building had quietly accumulated, and who would like the next founder to spend those two weeks on their product instead.
Pugazheanthi Palani is the founder of Nap OS, built by Napblog Limited in Dublin — an Industry Partner Member of the EdTech Ireland Network. Nap OS exhibits at the gradireland Graduate Careers Fair, RDS Dublin, on 6 October 2026.
