$ LP

// LP OÜ  ·  est. MMXXVI  ·  mobile utility studio

Ship small.
Diff often.

We make narrow mobile utilities for iOS and Android. Patient timelines, tight commits, no theatre. Six categories. One inbox. A short stack we have shipped with for years.

$ lp --status
> studio : ready.
> categories : 6 fixed.
> stack : short, deliberate.
> theatre : not found.
$ _

// 01 / what we build

ls categories/

Six fixed categories. We work in these and only these — taking on a category we have not shipped well in is, in our experience, how a small studio quietly ships poorly.

Each entry below describes what the category looks like in our hands, and — usually more interestingly — what we will refuse to ship.

  1. 01 / category

    $ vpn --on

    VPN.

    `vpn --on`. That is the entire user-facing surface. Underneath: WireGuard, IKEv2, sane retry logic, and exactly zero dashboards. The toggle is the product.

  2. 02 / category

    $ audit --network

    Privacy utilities.

    We treat 'analytics on' as a code smell. Apps in this category do their work on-device, label every off-device call by hand, and let the user diff network activity if they care to.

  3. 03 / category

    $ mv | cp | rm

    File managers.

    `mv`, `cp`, `rm`, `du -sh` — for the small filesystem in someone's pocket. Operations are atomic, obvious, and undoable. There is no hosted sync hidden in the menu.

  4. 04 / category

    $ instrument --honest

    Battery & device.

    Phones do not get faster from a button. We instrument honestly: battery health curves, storage breakdowns, what is spinning the radio. We refuse to ship a placebo 'boost' button. Ever.

  5. 05 / category

    $ du -sh ~/Downloads

    Cleaners.

    Find big things, surface them, let the user delete them with their eyes open. The sweep animation lasts as long as the sweep took. Usually 1.2 seconds. We do not pad it.

  6. 06 / category

    $ convert in.* out.*

    Converters.

    Files in, files out. Image, audio, document. Drop a file, pick a format, get back a file. The original stays where it was — we do not delete sources to look efficient.

// 02 / stack

cat package.json

A short, deliberate kit. Anything outside of it has to earn its place — and most of the time it doesn't. The list below is what we have shipped real production traffic on, repeatedly.

// dependencies

SwiftSwiftUIKotlinComposeRevenueCatFirebase AuthGitHub ActionsSentryLinearFigma

// .npmignore

Cross-platform UI runtimesAd-mediation networksGrowth-hacking SDKsTelemetry-as-a-serviceHeadless CMS for static copyAnalytics with user-level tracking

// 03 / working principles

Four lines we ship by.

// n° 01

> Diff-first design.

Before we mock a screen, we describe the change as a diff against today. If the diff is interesting on paper, it is worth building. If it isn't, the mock would not have saved it.

// n° 02

> Stack discipline, not stack religion.

We are loyal to a short list of tools. Not because they are the best at everything, but because we have shipped with them long enough to know how they fail under pressure.

// n° 03

> Time-boxed cycles, not deadline death-marches.

Two-week cycles, decided in writing on Mondays. If a feature does not fit, it does not ship that cycle. The next cycle is two weeks away — closer than infinity.

// n° 04

> Optimize for the second commit.

First commits are easy. Second commits — the ones that touch the same code six weeks later — are the hard ones. We design for them, not for the demo gif.

// 04 / faq

man lp

The questions a first call usually opens with. Longer ones go in email — see below.

  • ? Do you publish under the LP brand?

    Almost never. Each title goes out under a publishing partner's brand. We are the engineering, design, and long-tail care team behind it. The store listing rarely mentions us, and that is a deliberate choice.

  • ? Can we audit your code before signing?

    Yes. We will set up read-only access on a representative repo so a senior engineer on your side can spend an hour with the code. We would rather show our work than describe it.

  • ? What happens to the IP after the project ships?

    Each engagement is structured project-by-project. Typically the partner owns the title's IP outright, while we keep our internal libraries and tooling. The split is written into the project brief on day one and not renegotiated mid-flight.

  • ? Do you do bug-bounty / security maintenance after launch?

    Yes, on a fixed monthly retainer. The retainer covers production hotfixes, routine SDK upgrades, and an annual dependency sweep. New features go through the regular two-week cycle.

  • ? Can you join a daily standup?

    We can, but we would rather not. The studio runs asynchronously by default. A written status update covers more ground in five minutes than a synchronous nine-AM call covers in fifteen, and it is searchable two months later.

// 05 / inbox

Email is the channel. We watch the inbox during the working day and reply by the next one. If your project has a real deadline, put a date in the subject line and we will prioritise honestly.

info@lp-ou.com

$ echo "short paragraph about what you'd ship" \
   | mail -s "cleaner app, possible RC by July" info@lp-ou.com
> queued.