Studio notes · Tbilisi and Singapore
Notes on building web and mobile products
Short, practical writing on web development, mobile applications and interface design. These notes come from project work: mistakes we see repeatedly, decisions that pay off later, and the parts of a build that clients find surprising. Read one before a kickoff call and you will ask better questions.
Start here
What these notes are for
Every note below started as a real conversation on a project. Some of them are about the order work happens in, some are about decisions that look small at the start and expensive six weeks later. None of them are a pitch for a particular tool. They are the questions we end up asking clients in the first two meetings, written down so you can read them before we meet.
If a note describes something you are living through right now, that is usually a good sign that a short call would save you time. The three that connect most often are content readiness, design systems and handoff — they all point at the same idea, that early decisions decide how expensive a build gets later.
Content readiness
Why most project delays start with content
Late copy is the quiet killer of timelines. Design can proceed with placeholder text for a while, but layout decisions depend on real content lengths, and a build cannot launch with lorem ipsum in the hero. The fix is unglamorous: agree who writes each page, and by when, before design starts.
If content genuinely is not ready, we would rather reduce scope for launch than stall the whole project waiting for a page that can ship in a second release. In practice that means naming which pages carry the offer and which can follow, so the first release still reads as finished rather than half-filled.
Before design starts
- Name the person who writes each page, not the team.
- Agree a date for real copy, and a shorter date for headlines.
- Decide which pages can wait for a second release.
- Send any existing copy, even rough, before wireframes.
Layout discipline
Mobile-first is a constraint, not a slogan
Designing for a phone first forces hierarchy decisions that desktop layouts let you avoid. When you only have one column and a thumb, you find out what actually matters on the page. Scaling up to desktop afterwards is straightforward; the reverse produces cramped, tap-hostile interfaces.
The practical test we apply: can the primary action be reached and understood on a small screen without zooming or precision tapping. If not, the layout is not finished.
Small-screen check
Can someone reach the main action with one thumb, without zooming, and understand what happens next?
Phone first
Hierarchy gets decided early, because there is only one column to argue with.
Desktop after
Widening a clear structure is quick. Compressing a wide one is where tap targets die.
Reuse
What a design system actually buys you
A design system is not a style guide PDF. It is a set of components with defined states, matched between design files and code. The return shows up in review cycles: fewer debates about spacing, fewer inconsistencies shipping, faster onboarding for new developers.
It also makes design work cheaper over time. When a component exists, a new screen is assembly rather than invention. The savings are boring and real: a button with a hover, focus and disabled state already written does not get re-argued on every new page.
Component, not artwork
A card carries its own states, spacing and type scale. Changing it once changes it everywhere it is used.
Fewer review comments
Spacing that was already agreed stops being re-litigated on every new screen.
Faster onboarding
A developer joining mid-project reads the system, not the history.
The awkward middle case
Choosing between a CMS and a custom build
The question is who edits the site after launch. If non-technical staff publish regularly, a CMS earns its keep, and WordPress remains a practical answer with custom fields configured to your content. If the site is a product interface with logic behind it, a custom build is cleaner.
The awkward middle case is a small marketing site with occasional updates. Often the simplest answer is a static build with a short deploy process, and we will suggest that when it fits. Publishing once a quarter does not need a content management layer nobody will log into.
Publish often
Non-technical editors, frequent updates: a CMS with custom fields pays for itself.
Product logic
Accounts, states and rules behind the screen: a custom build stays cleaner.
Update rarely
A handful of changes a year: static pages and a short deploy process.
Edge cases
The states nobody wants to design
Empty lists, failed payments, slow networks, expired sessions. These are where interfaces lose users, and they are usually skipped because the happy path is more fun to draw. We ask for them in the wireframe stage, when they cost a few hours instead of a rebuild.
A useful habit: for each screen, write one sentence about what it shows when the data does not arrive. If there is no answer, the design is incomplete.
For each screen, write one sentence about what it shows when the data does not arrive.
That sentence is the spec for the empty, loading and failure states. It is cheap to write and it is the difference between an interface that explains itself and one that leaves people guessing.
Before the data loads
Something in the shape of the real content, so the page does not jump.
When it fails
Plain language about what happened and one clear way forward.
When it is empty
Explain what belongs here and how to add the first item.
Distribution
Progressive web apps versus app stores
Not every product needs to be in the App Store. A progressive web app installs from the browser, works offline where needed, and updates without review cycles. For internal tools and some customer-facing products, that is enough reach at a fraction of the overhead.
The decision comes down to capabilities and distribution. If you need push notifications, camera integration or app store discovery, build the app. If you need a fast tool your users open daily, a PWA may serve better. Writing the two options down side by side usually settles it faster than debating them out loud.
Progressive web app
Installs from the browser, updates without a review queue, one codebase to maintain.
Native app
Reaches the store, uses device features directly, needs release cycles and store review.
The question to ask first
Does the product need a device capability or a store listing, or does it need to be fast to open every day?
Before the first call
What to prepare before a kickoff
A short brief beats a long one. Tell us the business goal, the audience, the deadline if there is one, and any systems the project must connect to. Links to two or three products you like, and one you do not, are worth more than a page of adjectives.
If you have existing code, design files or analytics access, mention it. Discovery is faster when we can read what already exists instead of guessing at it, and it changes the estimate more than any other single detail.
A useful brief covers
- The business goal in one sentence.
- Who the audience is and what they need to do.
- Any fixed deadline, and why it is fixed.
- Systems the project must connect to.
- Two products you admire, one you do not.
Working together
How to judge a development partner
Ask what happens after launch. Ask who owns the code. Ask how scope changes get handled. A team that answers those three clearly is probably worth talking to, regardless of the stack they use.
Be wary of fixed quotes for unscoped work. An estimate before discovery is a guess dressed up as a number, and it usually gets corrected later at the worst possible moment.
After launch
Who watches the site once it is live, and what the first month of support covers.
Code ownership
Who holds the repository and accounts, and what you take with you if you leave.
Scope changes
How new requests are estimated, approved and scheduled against the current release.
Handoff
Notes on handoff and documentation
The test of a handoff is whether another team can pick up the project without calling you. That means a repository that builds, a README that explains deployment, and design files with named components rather than loose frames.
We treat documentation as part of the deliverable, not a favour at the end. It is also the cheapest insurance against a project becoming unmaintainable, and it is the first thing anyone asks for when a new developer joins.
Repository
Clones and builds with the documented command, no tribal knowledge required.
README
Explains environments, deployment steps and where the secrets live.
Design files
Named components that match the code, instead of loose frames on a canvas.
Reading order
Reading these notes in sequence
The notes are written to be read individually, but a few connect: content readiness, design systems and handoff all point at the same idea, that decisions made early determine how expensive a project gets later.
If one of them describes a problem you are currently living with, that is a good opening for an enquiry. Send the note you recognise and a sentence about your project, and we will tell you honestly whether it is a short fix or a rebuild.
Next step
Send the note you recognise
Tell us which note matches your situation and a sentence about the project. We will answer with what we would do first, whether that is a small fix or a longer build. For a fuller picture of how we work, read about our process or see our services before you write.
63 Bits LLC · ул. Мицкевича, 14, Тбилиси 0194, Грузия · +65 6212 2731 · [email protected] · Monday to Friday, 9:00 AM – 6:00 PM