What do you want to create?
Every build moves through the same five stages, in the same order, each one there to make the next cheaper to get right.
Before we write code, we agree in writing on what we're building: what's in, what's out, and what done means. Anything that changes after that is a decision we make together, not a drift we discover later.
You see something you can click before you see long documents or polished screens. A working prototype is the cheapest place to change your mind, so we get you there first.
The build runs in short iterations, each checked against the locked scope and against measured results: real load times, real devices, real user flows. Progress is something you can open in a browser, not a status report.
Launch lands on infrastructure we operate ourselves, so launch day is a deploy, not a leap. The code is yours from day one; the ground under it is our job to keep steady.
Shipping is a stage, not the finish. We stay on for updates, fixes, and the small details that keep software feeling looked after. With one founder in Orlando and one in Baguio, a question sent at night is usually answered by morning.
The stepped marks in the margin are collation marks, borrowed from bookbinding, printed on the spine folds so a wrong order shows itself at a glance. A good process does the same.
“details matter”
Fernando runs the product side of FLH Media: client sites and web apps built on Rails and FastAPI, the hosting they run on, and mobile work in Flutter, with AI agents and retrieval pipelines added where they earn their place. He prototypes early, locks scope before the build starts, and ships in iterations measured against what the client actually needs.

The same answers you'd get on a call. When the honest one is “it depends,” we say what it depends on.
07 entries
Websites, mobile apps, and online stores, plus everything around them: brand identity, interface design, landing pages, APIs and integrations, hosting, and ongoing care. Some projects start from nothing; plenty are rebuilds of something that already exists. If what you need isn't in that list, we'll say so and point you toward someone better suited.
The two of us: Fernando in Orlando, Hyowon in Baguio. There's no account manager in between; the people you talk to are the people writing the code. And because we sit almost exactly half a day apart, the project rarely sleeps. A question sent in your evening is usually answered by your morning.
Three habits, in order. We prototype early, so you're reacting to something real instead of a document. We lock scope before building: what's in, what's out, in writing, so the plan can't quietly grow. Then we ship in iterations and measure each release against real results, not a single launch-day reveal. Details matter; the process exists to catch them early.
Honestly: it depends on scope, which is why we fix scope first. Once the prototype conversation has settled what we're building, you get a written quote and a timeline, and because the scope is locked, both hold.
You do. The repository, the design files, the accounts, the infrastructure: all of it is yours from day one, and all of it runs without us. If you ever leave, you leave with everything.
We stay. We run hosting and infrastructure for our clients, and Care & Support covers updates, fixes, and small improvements after release. Launch is also where measurement starts. We watch how the release actually performs and iterate against the numbers, not against opinions.
Yes. Rebuilds and migrations are normal work for us, not a favor. We build with Next.js, React, TypeScript, Rails, FastAPI, Flutter, Three.js, and Postgres, so most codebases land in familiar territory. The first step is a read-through of what you have; then we'll tell you plainly whether it needs a rescue or a restart.
Two people, no account managers, no relay race. Tell us what you are trying to build and you will hear back from whoever is going to build it.
Or write it down now
A paragraph is plenty. It lands in our inbox as a plain email, and a person answers it.