Building software nobody will screenshot
Published February 8, 2026 · 5 min read
Nobody will tweet about this
When I was working at InterRail, I built a lot of things that will never appear in a portfolio screenshot. No beautiful UI, no clever product. Just: an accountant used to spend half her day manually copying numbers from documents into Excel. Now she doesn't.
That's it. That's the whole story.
But honestly? That's some of the most satisfying work I've done.
What the actual problem was
InterRail is a logistics and infrastructure company. The back-office work involves a lot of paper: contracts, acts of completion, invoices, KPI reports for clients. Most of it was being handled manually.
A senior accountant would receive a PDF — a scanned act of completion from a partner company — and spend time extracting the numbers, verifying them against contract terms, entering them into a spreadsheet, and then creating the corresponding accounting entry. For every document. Every day.
The developers before me had built a basic CRM. But the accounting and document workflows were still manual.
What we built
The core piece was AI-assisted document processing. A document comes in — scanned PDF, sometimes handwritten, sometimes a Word export — and the system extracts the structured data: parties, amounts, dates, line items, payment terms.
We used an LLM to handle the extraction. The tricky part isn't the model call; it's the validation layer. You can't just trust what the model extracts. You need to:
- Cross-reference amounts against the contract stored in the system
- Flag discrepancies for human review rather than silently accepting them
- Handle the cases where the document is ambiguous or partially readable
The result: what used to take 15-20 minutes per document now takes under a minute, mostly human review of flagged items.
We also built:
Acts and contracts module. Create, version, sign-off flow. Not exciting to describe but eliminated a huge amount of email back-and-forth.
KPI dashboards for clients. InterRail reports performance metrics to its clients. Before: a report was assembled manually in Excel and sent as an attachment. After: clients have a portal, data updates automatically, the report is just a button.
Accounting automation. Standard entries for common transaction types, auto-suggested from the extracted document data. The accountant confirms or adjusts; she doesn't start from blank.
Why this work matters
Here's what I've learned: the impact of a consumer product is diffuse. You ship a feature, some percentage of users use it, you see it in some metric. The impact of a well-built internal tool is immediate and specific. You watch someone's workflow change in front of you.
The accountant told me she could now leave work on time instead of staying late to finish data entry. That's real. That's more tangible than a conversion rate improvement.
I think there's a bias in tech culture toward "product" work — things you can show, things that are publicly visible. Internal tools get less prestige even when they deliver more measurable value per hour of engineering time.
The unglamorous lessons
Data quality is always the real problem. The documents are inconsistent. Partner companies use different formats. Amounts are expressed differently. Building the extraction is maybe 30% of the work; building the normalization and validation is 70%.
Build for the actual user, not the spec. The accountant doesn't want a "document processing system." She wants to not do the boring parts of her job. The frame matters.
Internal users will tell you exactly what's wrong. Consumer users churn silently. Internal users come to your desk. This is a feature, not a bug — it's the fastest feedback loop I've experienced in software.
I'm proud of this work even though nobody will ever screenshot it.