Build for the network your users actually have
Your office Wi-Fi is not your user's connection. Designing for real phones and paid-for data changes what good engineering looks like.
Most software is tested on fast laptops over office Wi-Fi. Most of its users are on a mid-range phone, on a mobile connection that drops in a lift, paying for every megabyte out of their own pocket. If you build for the first situation, you are building for your team, not your customers.
Treat bytes as your user's money
On prepaid mobile data, a heavy page is not just slow; it costs the visitor something. That changes the question from "is it fast enough?" to "is every byte earning its place?" A few habits make a large difference:
- Set a budget for page weight and JavaScript, write it into the brief, and fail the build when a change exceeds it.
- Send images at the size they are shown, in modern formats, and lazy-load anything below the fold.
- Question every dependency. A library that saves an afternoon of work can add weight to every page view for years.
Assume the connection will fail
Requests time out halfway. Users switch apps mid-payment. Good software expects this:
- Show what you already have while you fetch what you need, instead of a blank spinner.
- Make important actions safe to retry, so a second tap does not charge twice.
- Save form input locally so a dropped connection does not erase a long application.
A feature that only works on a perfect connection is a feature that sometimes does not work.
Test on the real thing
Keep an inexpensive Android phone in the office and use it. Throttle your browser to a slow mobile profile when you test. Watch someone use your product on the bus. These are cheap habits, and they reveal problems no fast laptop ever will.
Fast is a feature everyone notices
Nobody writes a review praising a page that loaded quickly. But every user feels it, every time, and the products that respect people's time and data are the ones they come back to.
One thing to do today: open your product on a mid-range phone with mobile data, clear the cache, and time how long the main page takes to become usable. Write the number down. That is your real performance.
Retrieval before fine-tuning: making an LLM answer from your own documents
If you want a language model to answer from your company's documents, start with retrieval, not training. A worked example, from the first document to the first honest measurement.
Test your AI feature like you would test a payments flow
Nobody ships a payments change because it looked fine in a demo. AI features deserve the same discipline. A worked example of building an evaluation suite your team will actually use.
Start with the decision, not the model
Most AI projects that stall were never wrong about the model. They were vague about the decision the model was meant to improve. How to start from the decision, with a worked example.
The one-page brief that saves a month of building
Before any code, we write one page. It is the cheapest month of rework you will ever avoid.