Build in Public Highlight: Tasu and the Decision Before the Code

The Fastest Part Is Not Always The Hardest

I have been thinking about a strange shift in building software.

The code is getting faster.

A founder can move from an idea to a working mobile app in less time than ever. Screens can be generated, flows can be rearranged, copy can be rewritten, and another version can be in review before the previous lesson has fully settled.

But speed does not remove the decision that comes before the code.

Should the paywall appear before or after someone feels the value of the product? Should there be a free trial? Should it last three days, seven days, or longer? Should the offer be weekly, monthly, annual, or some combination that makes the choice easier instead of more confusing?

All of those versions can be built.

The hard part is knowing which one deserves to be built first.

Where Mobile Monetization Becomes Guesswork

Mobile app growth is full of choices that look small in a design file and become enormous once they touch revenue.

A different onboarding sequence changes what a user understands before seeing the price. A different trial changes how much time the product has to create an aha moment. A different billing period can change both the conversion rate today and the retention curve months from now.

The uncomfortable part is that founders rarely make these decisions with clean information.

We collect screenshots from competitors. We remember a thread we read months ago. We look at what a successful app is doing and copy the visible part without knowing the category, audience, traffic source, or experiments that made it work.

That is not irrational. It is what happens when the available advice is scattered across reports, teardowns, posts, and dashboards.

But it creates a quiet gap between being able to ship an experiment and having a good reason to choose that experiment.

The real bottleneck: Faster implementation makes weak decisions cheaper to ship, but it does not make them less expensive to learn from.

Where Tasu Fits Into The Problem

I recently came across Tasu, built by @JeremyLasne, and what caught my attention was the restraint of the format.

Tasu is a newsletter for mobile app founders and app scalers. Its promise is simple: one actionable tip a day from founders scaling mobile apps and making revenue.

I like that cadence because it treats app monetization as a sequence of decisions, not one giant growth strategy that has to be solved in a weekend.

One day the useful question might be when to ask for an App Store review. Another might be whether a free trial should require a card, what to show when someone dismisses a paywall, or when paid acquisition is too early because the product is not converting enough of its organic downloads.

These are narrow questions, but they are close to the work.

They can become a changed screen, a new experiment, or a reason to leave the current flow alone.

The Value Of A Durable Library

A daily email can create focus, but it can also disappear into an inbox.

That is why the Tasu library makes the newsletter more interesting to me. It turns the daily ideas into a research archive organized around app teardowns, onboarding, paywalls, pricing, growth, retention, and subscription benchmarks.

The teardowns look at real app flows and the choices hidden inside them. The deep dives pull repeated patterns out of those examples. The benchmark breakdowns add context from larger datasets, including trial behavior, revenue per install, billing periods, geography, and churn.

That combination matters because a paywall never exists alone.

It sits at the end of an onboarding sequence. It makes a promise about value. It asks for a price that has to fit the category and the moment. It begins a retention problem the second someone pays.

Looking at one screenshot can hide all of that. A library lets the founder return to the larger pattern when the decision becomes real.

Bringing The Answer Closer To The Build

There is another part of Tasu that feels especially relevant now.

The newsletter also makes its research available through an MCP for coding agents. That means a founder can ask an onboarding, paywall, pricing, or retention question while working inside tools like Codex, Cursor, Claude, or VS Code.

I do not think the important idea is simply that the answer comes from AI.

The important idea is where the question gets asked.

Research usually happens in one context and implementation in another. Somewhere between the open tabs and the codebase, the nuance gets compressed into a vague instruction: add a trial, move the paywall, shorten the onboarding.

Putting the research closer to the build can preserve more of the conditions behind the recommendation. It creates a chance to ask not only what successful apps do, but when that pattern makes sense for this product.

That is a more useful kind of speed.

What I Am Taking From It

What I take from Tasu is not that benchmarks can make product decisions automatic.

They cannot.

Every app still has its own audience, promise, category, and stage. A pattern that works for a mature subscription business can be the wrong lesson for a founder still trying to create the first moment of value.

But research can make the starting point less arbitrary.

It can replace "this looks common" with a better question. It can give an experiment a reason. And it can remind a founder that conversion is not one screen, but a chain of trust that begins before the paywall and continues long after the purchase.

As building gets faster, I think this kind of judgment becomes more valuable, not less.

The code can produce many possible versions.

The founder still has to decide which possibility is worth testing.