In most IT projects, the deadline is negotiable. The client wants it sooner, the team asks for another fortnight, someone pushes the release by a sprint, and nothing catastrophic happens. A regulatory project works differently: the date the obligation takes effect is written into legislation, and legislation does not get renegotiated at a stand-up.
When we began work on our own SaaS product for mandatory electronic invoicing, we had a single fixed reference point that nobody could move. Poland's KSeF timetable was confirmed by an act passed on 5 August 2025 and signed into law on 27 August 2025. From 1 February 2026 the obligation applied to large taxpayers, from 1 April 2026 to the remaining businesses, and from 1 January 2027 it will apply to micro-enterprises. Three dates. Zero flexibility.
This is a process case study, not a technology one. We will not discuss framework selection. We will discuss how we made scope decisions, what we deliberately cut from the MVP, and how we built a product that survived a change in the law during its own construction.
Why a regulatory project is a different class of risk
The classic project triangle assumes you can manoeuvre across three variables: scope, time and budget. In a project governed by a statutory deadline, one of them turns to concrete. Two remain — and only one of those is genuinely flexible.
The scale of the risk is well documented. Research by McKinsey in collaboration with the University of Oxford, covering more than 5,400 large IT projects, found that on average they run 45% over budget, 7% over schedule and deliver 56% less value than predicted. In a commercial project, that 7% overrun is an inconvenience. In a regulatory project, it is the moment your customers lose the ability to invoice lawfully.
Three kinds of deadline, and only one that is genuinely hard
It is worth distinguishing which kind of deadline you are actually facing, because the entire planning logic follows from it:
A commercial deadline — we want to reach the market before a competitor. Movable; the cost is market share.
A contractual deadline — written into an agreement with a client. Movable; the cost is a penalty clause or a relationship.
A statutory deadline — written into legislation. Immovable; the cost is legal compliance.
Only the third type forces you to invert the standard planning process. You stop asking "how long will this scope take?" and start asking "what scope can realistically be built by this date?". It looks like a cosmetic difference. It rebuilds the way an entire team works.
The consequence: scope becomes the only variable
Budget in a product project is in practice equally rigid — you will not double the money halfway through, and you will not double the team without losing velocity. Brooks's Law applies regardless of sector: adding people to a late project makes it later.
That leaves scope. And scope therefore demands the most disciplined decision-making in the entire undertaking. Not "what would be nice to have", but "what does the customer need in order not to break the law on 1 April".
Prioritising scope: what made the MVP and what we deferred
The Standish Group has shown for years that the large majority of features in business systems are used rarely or never — in the organisation's well-known analysis, around 45% of delivered functionality was never used at all. In a project without time pressure, that is waste. In a project governed by legislation, it is an existential threat, because every hour spent on an optional feature is an hour taken from a mandatory one.
We adopted a single overriding criterion that settled every argument about priority.
The test: "without this, does the customer break the law?"
Every proposed feature went through a three-tier filter:
Compliance-blocking — without it, the user cannot discharge a statutory obligation. Into the MVP, no debate.
Operationally blocking — the user technically complies, but the process is so painful that it is unusable in practice. Included if it fits the window.
Value-adding — improves the experience, saves time, differentiates the product. Not before the deadline. Full stop.
This sounds trivial until you have to apply it to a feature you genuinely want to build. The discipline lies in refusing to promote items from tier three to tier one through creative argument.
What went into the first release
The MVP closed around a handful of areas, each mapping directly onto a statutory obligation:
Issuing and transmitting structured invoices in the schema currently in force.
Receiving inbound documents — because from 1 February 2026 every VAT-registered business must be able to receive invoices from the system, regardless of when its own issuing obligation begins.
Authentication and permission management: who inside the company is entitled to act on invoices.
Handling corrections, advance invoices and settlement invoices — the document types without which finance cannot close a month.
Retrieving official confirmation of receipt and archiving proof of transmission.
Basic observability: what was sent, what was rejected, and why.
What we deliberately deferred
The deferred list was longer than the delivered list — which is a healthy signal, not a failure:
Extensive analytics and management dashboards.
Machine-learning-based cost categorisation.
Deep two-way integrations with third-party accounting systems.
Sophisticated multi-level approval workflows.
A mobile application.
Document appearance customisation beyond the minimum.
The rule we held to: deferred does not mean cancelled, but it must be written down. Every postponed feature went into a register with a rationale and a provisional return date. That turned the stakeholder conversation from "we're not doing that" into "we'll do that in the quarter after launch, and here is why not sooner".
How we talked about scope with stakeholders
The most underrated part of prioritisation is not making the decisions but communicating them. The person responsible for sales sees a deferred feature as a lost argument in a client conversation. The person in finance sees a risk the product team cannot see.
Rather than defending decisions, we began showing their opportunity cost. Every proposal to widen scope was priced not in person-days but in what would have to drop out of the MVP to accommodate it. The conversation "what are we removing to add this?" ends very differently from "can we squeeze this in?".
The second tool was a weekly one-page status with a single number at the top: days remaining until the statutory date. No burndown charts, no percentage complete. That one number ordered priorities more effectively than any planning document.
The transition period, or several versions of reality at once
The hardest element of the entire undertaking had nothing to do with launch day. The point is that a legislator — quite sensibly — does not switch an entire economy over with one lever. A phased timetable means that for many months, different legal states coexist in the market.
In practice, our product had to serve simultaneously: businesses already inside the obligation, businesses not yet inside it but already required to receive, and entities relying on transitional exemptions. The exemption for the smallest taxpayers covered transactions up to PLN 450 per invoice and up to PLN 10,000 of monthly sales — which means the system must know each customer's context, not merely the calendar.
Schema versioning as a product feature, not technical debt
The gravest mistake in a project like this is treating the data format as fixed. The structured invoice schema changed during the rollout: a new version replaced its predecessor and introduced, among other things, dedicated fields linking a settlement invoice to its advance invoice.
We therefore designed multi-version schema support as a first-class feature of the system. A document is stored in an internal model independent of the official format, and translation into a specific version happens at the boundary, according to the date and the taxpayer's context. That single architectural decision repaid itself several times over.
Data migrates more slowly than the law
The second lesson of a transition period concerns historical documents. An invoice issued under the previous regime must remain readable, correctable and archived for years after the rules change. A correction to a document created before a format change is a distinct and non-trivial business case; the tax authority has issued individual rulings on precisely this point.
The conclusion for any organisation planning a comparable rollout: plan for the past before you plan for the future. Historical data migration is usually the most underestimated item in the schedule.
When the law changes mid-build
The most instructive moment of the project arrived after the first phase had already gone live. On 9 June 2026 the Ministry of Finance held open consultations following partial implementation of the system, at which a set of proposed improvements was presented.
One of them bore directly on a layer we had already built. Tokens as an authentication method had been scheduled for phase-out by the end of 2026, but in response to market feedback the ministry proposed retaining them beyond 31 December 2026 as well. The stated reasons were user interest in the tool, its security, and its convenience in day-to-day work. The proposal also introduced token validity periods of between 1 and 365 days and a mechanism for automatic renewal with the owner's prior consent.
Why this was good news that could have been a disaster
We had built the authentication layer on the assumption that tokens would be retired and certificates would become the target method. Had that layer been woven directly into business logic, the change of direction would have meant rewriting a substantial part of the system in the middle of peak season.
Because authentication methods had been treated from the outset as interchangeable plug-ins behind a common interface, adapting came down to a configuration change and the addition of token lifecycle handling. A few days of work instead of several weeks.
The rule: design for the direction, not the letter
From that experience we derived a rule we now apply across every regulatory project: implement the current letter of the rule, but design the structure around the direction the rule might travel. Where consultations suggest something may be retained, extended or clarified, that uncertainty should be visible in the architecture as a point of flexibility — not buried in the code as an assumption.
Architecture that withstands regulatory change — four principles
Regulatory resilience is not a property of technology. It is a way of distributing responsibility inside a system. Four principles that held up for us:
1. Business rules separated from application code
Thresholds, effective dates, exemption lists and qualifying conditions are configuration data, not conditional statements scattered across the application. Changing a threshold is an entry change, not a release.
2. An isolating layer over the public API
State systems move at their own pace, impose their own limits and have their own outages. Our product talks to them through a dedicated adaptation layer that translates the external model into the internal one. There is a purely operational dimension to this as well: interactive-mode request limits stand at 10 invoices per second, 30 per minute and 180 per hour, with retrieval limits of 8, 16 and 64 respectively. Queuing and throughput control have to be designed in on day one, not bolted on after the first month-end peak.
3. Feature flags tied to effective dates
Every scope item that depends on a rule has its own flag and its own activation calendar. Code for a new obligation therefore reaches production well in advance but only "wakes up" on the day the rule takes effect — and if the date moves, you change a date rather than a codebase.
4. Full auditability instead of overwriting
In a regulated environment, change history is not a luxury; it is evidence. Tellingly, the legislator is heading the same way: among the changes proposed is recording the full history of data modifications on invoices, because at present each successive edit overwrites the last and the process cannot be traced. If the state concludes it needs a complete audit trail, a system that has to answer inspection questions needs one all the more.
Six lessons for organisations facing their own statutory date
The scale involved was real: the system processed more than 340 million invoices issued by over 2.1 million entities. That demonstrates that with a well-run process, delivery on time is achievable even at the scale of an entire economy. Our takeaways:
Fix the date you count backwards from and make it untouchable. Every other decision derives from it.
Define one prioritisation criterion and apply it mechanically. The less room for discretion, the fewer arguments at the critical moment.
Build for the transition period, not for the target date. Version coexistence lasts far longer than the switchover itself.
Treat regulatory uncertainty as an architectural requirement. Wherever a rule may change, you need a replaceable seam.
Go live earlier than you must. A penalty-free window is time to learn the process, not a reason to delay; sanctions return in full once it closes.
Record what you did not build. A register of deliberate omissions is your only defence against "why isn't this here?" three months later.
In summary
A project governed by a statutory deadline is not technically harder than any other. It is harder to decide. It requires the organisation to accept that the first version will be narrower than anyone wanted, and that some genuinely good ideas will wait.
What actually determines success is three things: uncompromising scope discipline, designing the transition period as a legitimate system state in its own right, and an architecture that assumes the rules will change again. Because they will — the only question is whether they find you ready.
If your organisation is facing its own regulatory date — a reporting obligation, a sector requirement, or a change that will force a process rebuild — do not start with the technology question. Start with the scope question, and with what is ready to be deferred.
If you want a system built around your company's actual processes, get in touch. Our team will help you translate business objectives into concrete IT solutions. We will arrange a free consultation to review your timetable, identify the elements that are critical to compliance and propose a realistic implementation plan.
