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 building Neartail's 0→1 website builder. This one covers what came after adapting it 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.
- Live on Google Workspace Marketplace. 4.6★, 2,000+ installs, 150+ live websites.
PRODUCT
NEARTAIL WEBSITE BUILDER
Mobile web design
TIMELINE
1 MONTH
Sequential to desktop
TEAM
MOBILE LEAD (OWNED ADAPTATION)
Senior led desktop foundation
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.
Challenge
Two real problems. One small screen.
Behind the surface “make it mobile” framing, there were two specific problems that took the bulk of the month:
- Touch replacing drag-and-drop. The desktop builder leaned on hover, click-to-reveal, and precision pointing. None of that survives 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 coexisting, never competing at the same time.
These weren't independent. Solving touch created the hierarchy problem (more layered surfaces = more things to navigate between). Solving hierarchy constrained which touch patterns I could use (deeper hierarchy = more taps, which kills the speed goal).
Translation Rules
How desktop patterns crossed over. Or didn't.
I walked every desktop interaction and asked: 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.
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. Editing surfaces appear over the canvas, never beside it.
RULE 02
Tap to edit. Sheet to refine. Modal to focus.
Three tiers, each with a clear job. Single tap selects. Bottom sheet handles quick edits (text, colour, toggle). Full-screen modal handles deep edits (image picker, layout swap).
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.
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.
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 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.
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.
