01
Say the true thing
If something is barely started, the roadmap says so. If an idea turns out to be wrong, we drop it and say why rather than quietly shipping it anyway. Optimistic status reports are just deferred disappointment.
A small studio, deliberately
Beratna Labs is an independent software studio. We're new as a company and honest about it — but the engineering behind it isn't new, and the way we work comes from years of watching how software gets built badly.
Our story
Started over a familiar frustration
Most software gets built to a deadline somebody picked before anyone understood the problem. The result is predictable: features nobody asked for, a settings page full of things you'd never opt into, and a codebase that becomes unmaintainable about eighteen months in.
It doesn't have to work that way. Small teams with no pressure to grow at any cost can afford to do the unglamorous things — write the tests, document the decisions, say no to the feature that would look good in a screenshot and make the product worse.
That's what Beratna Labs is set up to do. Two products are out the door now — Portari and CoverText — and the roadmap behind them is deliberately short. We'd rather build a small number of things properly than a large number of things quickly.
The name
Beratna
Beratna means brother — someone with a stake in how things turn out for you. That's the posture we want toward the people who eventually use what we build. Not users to be measured and monetised. People we'd have to face.
And Labs, because software is built by testing ideas against reality, not by declaring them finished in a plan.
What we believe
Four things we don't compromise on
02
Write code for the next person
Someone will read this codebase in two years, and it may not be us. So: clear naming, sane structure, real documentation, no clever tricks that need a footnote. Maintainability is part of the work, not a cleanup phase.
03
Your data is not the product
We don't sell data, broker it, or design features whose real purpose is collecting more of it. If something only works by harvesting what people didn't mean to give us, it doesn't get built.
04
Quality isn't a phase
Fast loads, keyboard accessibility, sensible contrast, and layouts that hold up on a small screen aren't a hardening sprint at the end. They're what the word "finished" is supposed to mean.
Choosing the work
How we decide what to build
Saying no is most of this job. An idea has to clear all six of these before it gets a line of code, and plenty don't.
- We've hit the problem ourselves. Not read about it, not extrapolated from a market report — actually been annoyed by it.
- Nothing good already solves it. If a tool out there does the job well, the honest answer is to use it and move on.
- Other people confirm it independently. We go and ask before we build. If nobody else recognises the problem, it was probably just us.
- It can be small and still be useful. If the idea only works as a sprawling platform, a two-person studio has no business starting it.
- It works without exploiting anyone. No dark patterns, no engagement traps, no business model that needs people to make mistakes.
- We'd still want it in five years. Building something we'd abandon once the novelty wore off is a waste of everyone's time, ours included.
Where we're headed
The honest answer is: heads down, building. When something is genuinely ready for other people to depend on, it'll appear on the applications page as available — and not one day before that.
Follow along
We'll tell you when it's ready
One email when something enters beta. That's the whole arrangement.