The engineering behind Aevu

I’ve been building Aevu, a photo and video app with a simple premise: the feed should be ranked around what you actually enjoy, not around a follower contest. No comments, no public downvote counts, no friend graph, no location by default. The marketing line is “good things, less noise.”

That calmness is a product decision, but it’s also an engineering decision, and this post is about the second part. It turns out that removing features is not the same as removing work. When you take away comments and follower counts, everything that remains has to be very good, because there is nothing else on the screen.

Your taste is the graph

Most social apps bootstrap relevance from the social graph: import your contacts, follow some people, and the feed infers the rest. Aevu deliberately has no friend graph, so the graph had to come from somewhere else. The answer is interests plus private signals.

You pick subjects you want more of during onboarding, so the first feed is useful before you’ve interacted with anything. From there, likes, saves, watch behaviour, and private skips refine the view. The most interesting signal is “Not for me”: it marks one post for you alone. It doesn’t punish the creator, doesn’t decay an interest globally, and is never displayed as a public verdict. Negative feedback becomes pure ranking input instead of a social weapon.

This constraint shaped the data model early. Feedback is stored per-person, per-post, and the ranking layer never needed a notion of follower counts at all. What people keep instead is creators, privately, in a “Kept” lane, with no public count on either side.

The stack is deliberately boring

Regular readers will be shocked to learn that I did not use this project as an excuse to try six new databases. The client is React Native, shipping to iOS and Android from one codebase. Behind it sits a small Go API, a relational database that has earned decades of trust, and private object storage for media. Raw uploads go straight to storage through short-lived signed URLs, so original media never flows through the API and never becomes publicly addressable.

Everything else follows the same philosophy: infrastructure declared as code, secrets kept out of the codebase, and a deployment pipeline with no long-lived credentials in it. None of this is novel, which is exactly the point. The novelty budget went into the product.

The app: calm, quiet, no pressure The pipeline behind it: a state machine with trust issues

The media pipeline is a state machine

The hardest part of a media app is not showing pictures. It’s everything between “user taps publish” and “post is safely in a feed.” Uploads fail halfway. Renders fail. Moderation checks time out. People cancel drafts. If you model this loosely, you end up with orphaned files, half-published posts, and feeds showing media that was never cleared.

So the media lifecycle is written down as an explicit state contract before it is code, roughly:

upload    created -> uploading -> uploaded -> processing -> ready
                                          \-> failed (retryable)
render    queued -> running -> ready | failed (retryable)
post      processing -> ready, and only ready posts can reach a feed

A few principles carry the whole design. Raw media is private input and never appears in a feed response. A post becomes feed-eligible only when every one of its assets has been rendered and cleared, so a half-processed post simply does not exist as far as the feed is concerned. Publishing is atomic; a cancelled draft abandons everything, because a partially cancelled post must never be publishable. And when a draft or post dies, every storage object it owned is scheduled for deletion. No orphans.

Idempotency is the principle I’d tattoo somewhere visible. Mobile networks re-send things. Background upload queues retry. If “complete upload” isn’t safely repeatable, every flaky connection mints duplicate assets and duplicate processing work. In Aevu, replaying a completion is a no-op, and any given processing job is claimed by exactly one worker at a time.

Editing follows the same shape: the client captures a recipe of filters, adjustments, text, trims, and sound, and rendering happens server-side, producing the derivatives that actually ship, including adaptive streams for video. The upload is the raw material; the recipe is the edit; the pipeline is the darkroom.

Moderation fails closed

A comment-free app still needs trust and safety, arguably more, because the content is the only surface. Every image and every video goes through automated screening before it is ever eligible for a feed, and the system fails closed: if screening can’t complete, the post does not ship. There is no code path where “the checker was down” results in unreviewed media reaching people.

Anything borderline is routed to private human review, with graduated outcomes rather than a single ban hammer: content can be allowed, limited, or removed. Clear-cut violations are handled automatically but remain appealable, and an appeal produces an auditable review rather than a shrug. Designing the unhappy paths first is most of what trust and safety engineering actually is.

What’s next

The next slice is the event-driven half of the pipeline: moving media processing onto queues and workers, and putting delivery behind a proper CDN as the library of content grows. The rule I’m trying to hold: nothing ships as a pretend-complete placeholder.

The lesson so far: a calm product is not less engineering, it’s the same engineering with the volume knob removed. When there’s no engagement machinery to hide behind, the state machine is the feature.

Aevu is in private testing for iOS and Android. If that sounds like your kind of feed, ask about testing.