BuddyHQ.AI
2025An AI content engine that turns customer feedback into branded, publish-ready marketing assets.
A website builder that fits in one hand.
Adapting Neartail's desktop website builder for the small business owners who run their world from a phone.
I'm Live!
Website Link
30-second overview
- The desktop case study covered how we built Neartail's 0→1 website builder. This one covers what came after adapting that builder to mobile so business owners could edit their site from a phone.
- I owned the mobile adaptation end-to-end: translating the three-panel desktop layout into a stacked, touch-native experience without losing the inline-editing principle that made desktop work.
- The mobile builder ships inside the same product live on Google Workspace Marketplace 2,000+ installs, 4.6★ rating, 150+ live websites built.
Overview & Context
Same product. Same principles. One hand.
The desktop builder shipped, picked up traction on the Google Workspace Marketplace, and started getting used by real bakeries, canteens, and small retailers. Then a pattern showed up: a lot of these owners run their business from their phone. Their forms, orders, and customer chats live there, not at a laptop.
If editing the website meant going back to a desktop, the builder didn't fit their actual workflow. So the next thing to design was the mobile version of the builder itself.
Impact
Shipped a full mobile builder not a viewer, not a stripped version. Edit, preview, and publish from a phone.
Translated the desktop's three-panel layout into a single-canvas, bottom-sheet-driven editor without losing the inline-editing principle.
Live in production. Builder maintains its 4.6★ rating and powers 150+ live websites across 2,000+ installs.
Problem
The desktop builder doesn't translate. Not directly.
Imagine you run a home bakery.
You launched your site with Neartail last month. Today you got a new order for a custom cake. You want to add it to your menu right now, before it slips your mind. You're on the bus. You have a phone.
If editing your site requires a laptop, you'll forget. If it works on the phone but it's painful, you'll forget too. The builder needs to be as quick as opening WhatsApp.
The desktop builder worked because it had room a left panel for pages and sections, a centered live canvas, and contextual controls that appeared inline on click. None of those affordances exist on a 380px screen. The vision had to flip: the canvas is the screen, and everything else gets summoned on top of it, only when needed.
My Note
The temptation is to “responsive-ify” the desktop. Same panels, smaller. That doesn't work for an editor. The desktop's left panel takes 240px that's 63% of a phone screen. The first real decision was: stop trying to fit. Start over from the canvas.
Challenge
Two real problems. One small screen.
Behind the surface “make it mobile” framing, there were two specific design problems that took up the bulk of the month:
- Touch interactions replacing drag-and-drop. The desktop builder leaned on hover, click-to-reveal, and precision pointing. None of that works on a phone.
- Information hierarchy collapse. Three panels of information had to live on one screen without becoming a maze. Pages, sections, edit fields, preview, and publish all had to coexist, but never compete at the same time.
These weren't independent. Solving touch created the hierarchy problem (more layered surfaces means more things to navigate between), and solving hierarchy constrained what touch patterns I could use (deeper hierarchy means more taps, which kills the speed goal).
The reframe
The desktop's promise was “see your change instantly.” The mobile's promise had to be “feel where you are instantly.” Speed of feedback shifted to clarity of location. That single reframe drove every layout decision that followed.
Translation Rules
How desktop patterns crossed over. Or didn't.
I started by walking through every desktop interaction and asking: does this exist because of the canvas, or because of the cursor? Cursor-bound interactions had to be redesigned. Canvas-bound ones could often stay. From that audit, four rules emerged that governed every design call.
RULE 01
Canvas first. Always.
The user came to edit their website the website should dominate the screen at all times, even while editing. No persistent drawer, no fixed sidebar, no top tab bar competing with the canvas. Editing surfaces appear over the canvas, never beside it.
RULE 02
Tap to edit. Sheet to refine. Modal to focus.
Three tiers. A single tap selects a section. A bottom sheet handles quick edits (text, colour, toggle). A full-screen modal handles deep edits (image picker, layout swap). Each tier has a clear job.
RULE 03
No drag. Reorder by lift.
Drag-and-drop on a phone is a precision sport mobile users keep losing. Section reordering uses long-press to lift, then tap-to-place confirmable, undo-able, forgiving. The user always knows what's selected and where it'll land.
RULE 04
Defaults still do the heavy lifting.
The desktop's superpower was that doing nothing already gave you a good website. Every mobile control inherits its desktop default. Users never have to touch a setting to ship they just touch the ones they care about. The builder still works on autopilot.
Editing Without a Cursor
Bottom sheet for the quick stuff. Full screen for the deep stuff.
The desktop builder's signature was inline editing click a section, controls appear on it. That precise pattern doesn't survive on a phone, because controls + finger + canvas = the user's thumb covers the thing they're editing. The mobile equivalent had to feel as direct without breaking that physics.
TIER 01
Tap
A single tap selects a section. A subtle highlight appears on the canvas. No editing UI yet just confirmation that the user has the right thing.
TIER 02
Bottom sheet
A quick-edit sheet rises from the bottom text, colour, layout toggle. Half-screen. The selected section stays visible. Most edits never go deeper.
TIER 03
Full screen
For complex edits image library, layout swap, content rewrite the sheet expands to a full-screen modal. The editing tool takes over; the user re-enters context on close.
The interesting decision wasn't the bottom sheet itself that's a known mobile pattern. It was which controls go in which tier. Anything the user might toggle without thinking belongs in the sheet. Anything that needs full attention belongs in the modal. The audit gave a clean classification: ~70% of desktop's contextual controls fit in the bottom sheet, ~30% needed the modal.
Preview and publish followed the same logic. The canvas is the preview dismissing the editing surfaces leaves exactly what a visitor sees. No mode switch, no reload. Publishing is a single floating action that only appears when something has changed, and disappears when there isn't.
Design × Dev
One month. Two designers in dialogue.
The mobile adaptation ran for about a month, after the desktop builder shipped. My senior who'd led the desktop work was the first reviewer on every mobile call. The constraint that made this productive: he'd already built the system, so every component change I proposed was a conversation about whether the mobile pattern broke a desktop assumption.
WEEK 01
Audit & rules
Walked every desktop interaction. Classified what carries over. Drafted the four translation rules. Got senior alignment before drawing screens.
WEEK 02–03
Interaction & layout
Designed the navigation model and three-tier editing flow. Iterated with engineering on what was build-feasible inside the existing codebase.
WEEK 04
Polish & handoff
Specced edge cases, long section names, empty states, network-loss publish. Handed off to the same engineering team that shipped desktop.
Impact & Outcomes
Same product, broader surface.
The mobile builder shipped as part of the same Neartail product on Google Workspace Marketplace. The metrics below are the product's marketplace metrics the mobile work contributed by giving existing users a way to actually use the builder where they live: their phones.
4.6
Rated on Google Workspace Marketplace, from real business owners using the product in production.
2K+
Installs on Google Workspace Marketplace, the product is live and publicly available.
150+
Live websites built with Neartail, many of them edited on mobile.
Live
Mobile builder shipped to production, full edit, preview, and publish flow on a phone.
Takeaways
What I took away.
1
Adapting is its own design discipline.
Going from desktop to mobile isn't shrinking, it's re-deciding with new physics. The principles can carry over, but the patterns almost never should. The job is to honour the foundation, not preserve its shape.
2
Inline editing is a principle, not a pattern.
On desktop, “inline” meant controls appeared on the section. On mobile, they have to leave it so the thumb doesn't cover it. The principle survived. The literal pattern didn't. Knowing which is which is the whole skill.
3
A summoned surface beats a permanent one when canvas is king.
Always-visible nav feels safe but eats the screen. On a phone, where the canvas is the product, a hidden-by-default panel that opens with one tap was the better trade. The cost of one tap is smaller than the cost of permanent UI.
4
Working off a senior's system trains a different muscle.
Inheriting a foundation forces a useful discipline, you stop redesigning for ego, and start asking which changes actually earn their place. Restraint becomes the design move.
5
Mobile builders fail at hierarchy, not features.
Feature parity was never the hard part, most desktop controls have a mobile equivalent. The hard part was where each control lives: tap, sheet, or modal. Hierarchy is the design product on mobile.
