EzLicence runs an Australian marketplace that processes $100M+ in annual bookings, with 250,000+ lesson hours booked each year. Seven years of continuous development produced the thing every maturing product eventually produces: knowledge that exists but cannot be found. Business requirements, product specifications, architectural decisions, change logs and release notes were spread across repositories, wikis, email threads and the memory of long-serving staff. New engineers spent their first weeks reconstructing context. Existing engineers re-investigated decisions that had already been made and written down somewhere invisible. And because none of it was structured, none of it could be handed to an AI tool that might have helped.
An AI knowledge system that consolidated seven years of product evolution, shipped in 4 weeks.
Seven years of decisions, in one place
PixelForce shipped an AI knowledge system called The Handbook for EzLicence in 4 weeks. It consolidated seven years of product evolution into one source of truth, delivers a 50 percent efficiency gain across workflows, and automates 90 percent of documentation updates with 10 percent human oversight.
Efficiency gain 50%
Documentation updates automated 90%
Consolidation to release 4 weeks
The Problem
The Solution
PixelForce designed and built The Handbook, an AI knowledge system that consolidates seven years of product evolution into one source of truth. The extraction work pulled from existing documents, archived communications, the code repository history and structured interviews with long-serving staff, then restructured the result so it explains not only what the system does but why each decision was taken. Critically, the information architecture was designed to be read by people and parsed by machines at the same time, so the documentation can be consumed directly by AI tooling without a preprocessing layer.
The Outcome
The Handbook shipped in 4 weeks. It delivers a 50 percent efficiency gain across workflows and automates 90 percent of documentation updates with 10 percent human oversight, so the knowledge base stays current as the product changes rather than ageing from the day it is written.
What happens to knowledge in year seven
EzLicence operates a two-sided marketplace connecting learner drivers with accredited independent driving instructors across Australia. The platform processes $100M+ in annual bookings and 250,000+ lesson hours are booked through it each year. PixelForce has worked with EzLicence across several engagements. This one was not about the marketplace. It was about the organisation that had grown up around it.
Seven years of continuous development leaves a residue. Every feature that shipped had a reason, every architectural choice had an alternative that was rejected, and almost none of that reasoning survives in a form anyone can retrieve two years later. The cost is quiet and compounding: onboarding stretches, teams rediscover settled decisions, and small inconsistencies accumulate in the product because nobody could confirm how the existing behaviour was meant to work. EzLicence also wanted to apply AI tooling to its development workflow and could not, because AI systems need structured, machine-readable source material and there was none. The brief was to fix the knowledge problem and the AI-readiness problem with the same piece of work.
Seven years, no single source
Requirements, specifications, change logs and architectural decisions lived across repositories, wikis, email threads and individual memory. There was no place to look first, so people asked a colleague or guessed.
Context walked out the door
As the team grew and changed, the reasoning behind long-standing decisions left with the people who made them. What remained was the code, which records what was done but never why.
Documentation that ages the day it ships
Hand-maintained documentation falls behind the product almost immediately, because updating it is always the least urgent task on someone's list. Any solution had to maintain itself or it would repeat the problem.
AI tooling had nothing to read
EzLicence wanted to apply AI to its development workflow. AI systems need well-structured, machine-readable source material, and scattered prose across a dozen systems is not that.
Most of the value in this project came out of conversations rather than files. The four weeks were structured around getting time with the people who had been at EzLicence longest, because they held the reasoning that no document recorded, and around short review cycles so that what the team wrote back could be corrected while the context was still fresh. EzLicence stayed close to the work throughout, which is what allowed a knowledge system to be built in four weeks rather than four months.
Hinney Lo Founder & CEO, PixelForce
Book a consultationDocumentation projects usually fail for the same reason: someone tidies the files, nobody updates them, and within a quarter the wiki is another place where information goes to be wrong. The only version worth building is one that maintains itself and knows when to ask a human. Getting that ratio right is the whole engineering problem.
Swipe to explore
How we built The Handbook
The engagement ran as a focused four-week programme and started with extraction rather than authoring. The team collected existing documentation, archived communications, commit history from the code repository and structured interviews with long-serving staff, then read across all of it for the implicit reasoning that no document stated outright. This is the part that cannot be automated and is the reason the result is worth having: copying files into a new system produces a tidier pile, not a source of truth. The output was restructured into a single narrative covering what exists now, how it came to exist, and which alternatives were considered and rejected.
The Handbook organises that material into discrete knowledge domains - product features, technical architecture, business logic, integrations and institutional decisions - each carrying its own context and its relationships to the others. The information architecture is the deliberate part. Conventional documentation optimises for a human reading a page, which produces visual hierarchy that machines have to guess at. The Handbook is structured so the same content is navigable by a person and directly parseable by a natural language processing system, which is what makes it usable as input to AI tooling without a custom parsing layer in between.
The maintenance model is what keeps it alive. Rather than relying on a person remembering to update a page after a release, The Handbook automates 90 percent of documentation updates, drawing on changes as they happen, with 10 percent human oversight for the judgement calls a model should not make alone. That ratio is the point of the design: enough automation that currency is the default state, and enough review that a wrong inference does not quietly become the record. Across EzLicence workflows, from requirements gathering and technical specification through to onboarding a new engineer, the system delivers a 50 percent efficiency gain, and the technical debt that accumulates as undocumented decisions now has somewhere to go.
Extract · Structure · Maintain
50 percent efficiency gain. 90 percent of updates automated.
Seven years of product evolution, consolidated into one source of truth in four weeks.
- Knowledge extraction
- AI-native structure
- Knowledge domains
- Decisions, not just descriptions
- Automated maintenance
- Onboarding and daily use
01 06
Knowledge extraction
The first phase collected everything that already existed - documents, archived communications, commit history and structured interviews with long-serving team members - and read across it for the reasoning that no single artefact stated.
This is the step that decides whether the result is a source of truth or a tidier pile of files. Institutional knowledge is mostly implicit, and it only becomes retrievable if someone deliberately asks the people who hold it.
02 06
AI-native structure
Conventional documentation optimises for a person reading a page, which encodes meaning in visual hierarchy that a machine has to infer. The Handbook encodes it in the structure instead, so the same content is navigable by a human and directly parseable by an AI system without a custom preprocessing layer.
03 06
Knowledge domains
Content is organised into discrete domains - product features, technical architecture, business logic, integrations and institutional decisions - each carrying its own context and its relationships to the others. A question about how a feature interacts with an integration has one place to be answered rather than three partial answers in three systems.
04 06
Decisions, not just descriptions
The Handbook records why choices were made and which alternatives were rejected, not only what the system does today. That is the layer that normally disappears with staff turnover, and it is the layer that stops a team relitigating a settled decision two years later.
05 06
Automated maintenance
The system automates 90 percent of documentation updates with 10 percent human oversight. Currency is the default state rather than a task someone has to remember, and the remaining oversight covers the judgement calls where a wrong inference should not be allowed to become the record.
06 06
Onboarding and daily use
A new engineer starts from a coherent narrative rather than a search across several systems, and an existing engineer confirms how something is meant to behave instead of reconstructing it. Across EzLicence workflows the system delivers a 50 percent efficiency gain.
Services behind The Handbook
Frequently Asked Questions
The Handbook is an AI knowledge system PixelForce built for EzLicence, the Australian online marketplace for booking driving lessons. It consolidates seven years of product evolution into a single source of truth covering product features, technical architecture, business logic, integrations and the reasoning behind past decisions. It was shipped in 4 weeks, delivers a 50 percent efficiency gain across workflows, and automates 90 percent of documentation updates with 10 percent human oversight.
A wiki is a place to put pages and relies on people remembering to update them, so it drifts out of date almost immediately. An AI knowledge system is structured so that machines can parse it directly and so that most updates happen automatically as the product changes, with humans reviewing the judgement calls. The difference is not the interface. It is that currency is designed in rather than left to discipline.
The Handbook was shipped in 4 weeks. The duration depends far more on how much undocumented history has to be extracted than on the software itself, because the hard part is interviewing long-serving staff and reading across archived material for reasoning that was never written down. PixelForce scopes this in Phase 1 Scoping and Design before quoting delivery, so the timeline is fixed once the extraction surface is understood rather than estimated in advance.
Scoping and delivery are priced separately at PixelForce. Phase 1 Scoping and Design runs $35,000 to $65,000 and produces the blueprint, and Phase 2 Development, QA and Release typically ranges between $100,000 and $350,000 depending on scope. A focused knowledge system for a single product sits well below a full platform build, because the effort is concentrated in extraction and structure rather than in application development. The figure is fixed in a Statement of Work before delivery starts.
By fixing the ratio deliberately rather than aiming for full automation. The Handbook automates 90 percent of documentation updates and keeps 10 percent under human oversight, and the 10 percent is not a leftover - it is the class of change where a model's inference should not be allowed to become the record unchallenged. Automation keeps the knowledge base current; review keeps it correct. A system that removes the human entirely trades one failure mode for a worse one.
It does if you intend to point AI tooling at it. Conventional documentation carries a lot of its meaning in visual hierarchy, which a model has to infer, so teams end up building custom parsing layers or accepting poor results. Structuring the content so a person and a machine read the same thing removes that layer entirely, and it is why The Handbook could be used as direct input to AI tooling from the day it shipped.
Two components. Model usage is billed by the AI provider the system runs on, at that provider's own published per-token rates, which change over time and should be checked on the provider's pricing page rather than quoted second-hand. Alongside that, PixelForce offers Phase 3 Post Launch Support as a warranty, monitoring and support arrangement from $4,000 per month, or as a full product retainer from Steady at $10,000 to Momentum at $50,000 per four-week cycle.
Up next
More products we have designed, built and launched end to end.
Schnuzzle Selling a sense you cannot photograph
PixelForce built Schnuzzle's Shopify store for its scent-disc dog toys. Schnuzzle saw a 200 percent return on investment within the launch period.
Fitstop From a Queensland garage to a four-country franchise
PixelForce built the Fitstop member app and franchisee operations portal across 100+ gyms and 50,000+ members, lifting retention by more than 10 percent.