The problem
App store review tells you what is wrong days after you submit. By then the release is already late, and every fix costs another review cycle to find out whether it worked.
The guidelines are the harder half. Apple's and Google's policies run to thousands of clauses, change without announcement, and are written as prose, judgement calls about intent, not rules a linter can match against.
The constraint
You are asking developers to hand over their codebase
Themis cannot do anything without reading source, and that is a lot to ask. The code being checked is usually unreleased, often commercially sensitive, and the person submitting it has no way to verify what happens to it afterwards.
So the rule came first and the rest was built around it: source is analysed in memory and never written to disk. No repository copy, no cache, nothing left behind to leak later.
Which runs straight into the other half of the product. Compliance is only useful as a trend, is this app getting closer to shippable, or further away? Trends need history, and history normally means keeping the thing you are tracking. Squaring those two is what shaped the storage layer.
What I built
- 01
Static analysis first, model second
Deterministic checks run before the LLM does. Missing permission strings, absent privacy declarations, banned API usage, these are pattern matches, and none of them should ever cost a model call.
Gemini 2.5 Flash is held back for the clauses that genuinely need judgement: whether a data-collection disclosure actually covers what the app does, whether a paywall is presented the way policy requires. Splitting it this way keeps the cost per scan predictable and the cheap checks instant.
- 02
Store the findings, never the source
Postgres holds findings, severities, rule identifiers and timestamps, enough to draw a trend line and diff one scan against the last. The code that produced them is gone the moment the scan ends.
History without custody. The dashboard can show three months of compliance movement without the service ever having retained a line of the application.
- 03
Output has to be pasteable
A finding that says "this violates 5.1.1" sends the developer off to a guideline document to work out what that means. A finding that carries the corrected snippet ends there.
Fixes are emitted as code you copy, not advice you interpret.
- 04
Meet the developer in CI, not in a portal
A compliance tool you have to remember to open is one you open the day before submitting, the worst possible day to learn something is wrong.
A GitHub Action and a CLI put the same check on every push, so problems surface while the code is still fresh in someone's head.
- 05
The rulebook is the product's shelf life
Store policies move, and a checker built against a snapshot rots silently. That failure is worse than no checker at all, because it keeps reporting clean while it goes out of date.
Keeping the guideline set current is ongoing maintenance, not something finished at launch.
What happened
Themis won the hackathon at Codematic. The judges were impressed enough that it turned into an interview, and the interview turned into a job, I have been a software engineer at Codematic since.
Judged work is a different bar from shipped work. It has to be explicable to someone seeing it cold, under time pressure, alongside everything else built that week. The privacy decision is what made it explicable: not storing source is a single sentence, and it answers the first objection anyone raises about handing a compliance tool their codebase.