PEPTIDE [FLW]
Monitoring, dosing, and tracking are what we deliver with this site. Animated videos explaining how the site works, historical dosing data, and even a place to record your labwork and health information alongside your peptide protocol.
Our own product, in production, with real users on it. It is where we prove the engineering we sell — the security, the offline behaviour, the deploy pipeline — on our own name before it goes anywhere near a client's.
Every security and reliability practice on this page is running on our own product first. Clients get the same engineering: the hand-written security policy, the two-layer login protection, and a deploy that refuses to report success until it can prove the new version is live.
The problem
A tool people open half-awake, first thing in the morning, that has to do arithmetic correctly, remember what happened yesterday, and warn them before they run out of something. Get any of the three wrong and it gets deleted.
Gallery
How we built it
Calm, clinical, legible at six in the morning
Soft greens on near-white, generous line spacing, and four cards that name what the tool does in one word each. People open it barely awake, so the design removes every decision that is not the one they came to make. Restraint is harder than decoration and it is what makes a tool feel trustworthy.
Four verbs, four screens
Calculate, log, manage, remind. Each is one screen that does one thing well. The architecture of the product is the architecture of the home page, so nobody ever has to learn where anything is.
Fast on a phone, because that is where it is used
91 out of 100 for mobile speed and zero layout shift — the number that mattered most here, because this is a phone product first. Behind a global network the first paint lands in four tenths of a second on desktop.
Deliberate about what happens on a bad connection
It installs to a home screen and the interface stays usable when the signal drops, while anything that writes data waits for a real connection and says so. A record that appears to save and is quietly lost is worse than an honest error message — knowing which half to cache is the whole design.
Built to our own standard, with nothing to hide behind
There was no client brief to defer to and no budget to blame — every decision here is one we made because we thought it was the right one. That makes it the clearest evidence available of what we do by default.
Stack
- Python
- Flask
- SQLite
- SQLAlchemy
- Alembic
- Service Worker
- Web Push
- Chart.js
- Cloudflare
- PythonAnywhere
Measured performance
Google PageSpeed Insights, 29 August 2026. Median of five runs, measured at this site's own address. Speed is the desktop figure. Where SEO, accessibility or best practices differ between mobile and desktop, the lower of the two is the one shown.
- Largest contentful paint
- 1.2 s
- First contentful paint
- 0.4 s
- Speed Index
- 0.6 s
- Layout shift on mobile
- 0
The decisions that mattered
A deploy that refuses to lie
Our host's reload API returns an error behind the network layer, and its file API will happily change bytes and report success without ever restarting the application — a green deploy that shipped nothing. So the pipeline reads the process counter before deploying, makes the change over a real connection, then watches the log until the counter proves the application actually restarted. If it does not, the job fails. Every client site we host is deployed with the same principle: a deploy is not finished until something has verified it.
A security policy written by hand, not copied
The browser is told exactly what this site is allowed to do: it cannot be embedded in someone else's page, its links cannot be redirected by an injected tag, its forms cannot be pointed at another server, and no unexpected background code can be installed. Each of those is aimed at a specific real attack rather than pasted from a generator. Most sites ship with none of it, and it costs nothing to have.
Two protections on the login, doing two different jobs
Repeated failed sign-ins lock that account temporarily. Underneath it, per-visitor rate limits on the login page, keyed so the limit follows the actual person rather than the network in front of them. Neither works alone: account lockout by itself hands anyone a way to lock a customer out on purpose, and rate limits by itself is a volume brake rather than a defence. Together they are the standard we apply to any site with a login on it.
What this means for your business
You do not need to care what this product does to see the point. It is the same security, the same reliability and the same standard of interface we bring to a store, a booking system or a client portal — proven on our own name, in production, with real people depending on it. If you are evaluating an agency, the honest question is what they run themselves. This is our answer.
Want a site that does this for you?
Start with a free audit — a written report on how your site performs today and what it would take to put it in this company. No pitch attached.
Get a free audit →