How I built Matury Online: an app with payments and AI essay grading, running since 2025
What happens under the hood of an exam-prep platform: what's a static page and what's an application, why it runs on a single server, how AI grades essays against official exam criteria, and where the traffic comes from. With Search Console numbers.
Karol Leszczyński · Toruń, Poland
For a year I built static websites: guides, company sites, landing pages. A static site is fast and nearly free to run, but it ends the moment a user needs to log in, save progress or submit an essay for grading. Matury Online is the first project where I crossed that line: a platform for preparing for the matura (Poland’s secondary-school final exam) in Polish, with a bank of official CKE exam tasks, interactive exam papers, AI essay grading against the official criteria and a full exam simulation. It has payments, accounts, job queues and users who pay.
This post describes how it’s built and what that means for a company that wants its own application. The numbers are current as of August 2026.
What’s a page and what’s an application
The service splits into two layers working on shared infrastructure.
| Layer | What it contains | How it’s built |
|---|---|---|
| Knowledge base | subject and reading-list pages, the task bank, an archive of CKE exam papers 2002–2026, blog, FAQ | static HTML, ready at publish time, served from the CloudFront network |
| Application | student dashboard, progress, task solving, AI-graded essays, exam simulation, payments | a Node.js server with a Postgres database and a job queue |
The knowledge base draws traffic from Google, some visitors create an account, and the account unlocks the application. Each layer does what it’s good at: the knowledge pages load in a fraction of a second and score 95–100 in Google’s speed measurement, while the application processes data where it has to.
One server instead of serverless
The model where you pay per call and have no server to babysit was tempting. I picked a single server with a database and a process manager, for three reasons.
Grading an essay with an AI model takes 15–40 seconds, and the result streams to the student in real time. In a serverless setup, long streaming operations like that are awkward and expensive. On your own server they’re an ordinary connection.
The cost at current traffic (a few hundred gradings a day plus the knowledge-base traffic) is about $30 for the server and disk, $15 for the CDN and domains, plus actual AI usage. All in, under $100 a month, on one bill you can predict.
Deploying a new version is a single command. The code lands on the server, builds next to the running version and swaps in within seconds; at most, users see a brief maintenance screen. Database backups run daily, a probe checks availability every minute, alerts arrive by email.
This simplicity has its price: if the server goes down, the whole service goes down. At the current scale, recovery time is measured in minutes and I accept that risk deliberately; when traffic grows, I’ll add a second machine.
AI essay grading: three approaches, one survived
A student writes an essay, clicks “grade”, and after a few dozen seconds gets points across the four official CKE criteria (content, composition, language and style, spelling and punctuation) with comments on what to improve. Getting this to produce repeatable results took several months.
The first version sent the model the whole text and the full criteria in one request. The results were random: 32 points out of 35 for a mediocre essay one time, 18 for a good one the next. The second version split the request by criterion but still graded them in one pass, so the assessment of one criterion bled into the next. The third stuck: each criterion is a separate request with its own instructions, two sample essays with real CKE grades per criterion, and the model’s randomness switched off. Only my server assembles the results. In tests on fifty essays with official CKE grades, the spread dropped to a level you can show a student.
The takeaway from those months is simple and carries over to any AI rollout in a company: one request to a model won’t give you a repeatable assessment; five small requests arranged into a process will. Add to that a bill calculated per call and a cap, so a user with fifty essays doesn’t generate an invoice nobody planned for.
Where the traffic comes from
For the first few months the matury-online.pl domain was nearly invisible in Google: queries like “matura polski” belong to services with fifteen-year-old content and enormous link profiles. The traffic came through a sister domain, maturapolski.pl, carrying the same knowledge base, indexed earlier and linked from my educational sites.
| Domain | Google clicks, 90 days | Impressions | Average position |
|---|---|---|---|
| maturapolski.pl | 6,881 | 148,608 | ~8 |
| matury-online.pl | 719 | 35,643 | climbing since spring |
Search Console data, 17 May – 13 Aug 2026. A static knowledge base acting as the gateway to the application worked better than trying to rank the application itself, and links from my own sites brought more traffic than paid ads.
How this maps onto your project
A business web application usually has the same shape: a public part that Google finds, and a part behind a login where customers work and pay. Matury Online shows it can be built and run for under a hundred dollars a month, with payments, a queue for long operations, backups and monitoring from day one. That’s exactly how I build custom web applications: from 15 000 zł net, with your own access to the code and the server. If you have an idea for a product where users create accounts, describe it in a few sentences; I’ll tell you what the first version would include and how long it would take.