Exotool: Product Assessment and Recommendations

Prepared for Hubert Lane by Cyrus Prescod · 4 November 2026

Hubert, this is my independent view of where Exotool stands today and the changes I think would matter most. I have built with the platform alongside you, and you have already acted on some of my earlier feedback. Everything below is meant as input for your decisions. It is not a request for work from me.

1. Owner brief

About this assessment

Evidence base. (1) My earlier reverse-engineering rundown (exotool-rea-rundown.md, “the rundown”). It is based on the editor's and generated apps' shipped JavaScript, the Exotool MCP tools, and a build of the Sponsor Desk example. (2) Read-only checks made for this report: the Exotool reference docs (overview, editor and language, published 22 Oct–2 Nov 2026), the preset catalogue, the list of 45 system samples, and the public previews of two samples and Sponsor Desk at desktop and phone widths. (3) Current first-party documentation from competing products, cited next to each claim. One limitation: I did not sign in to the editor, so the canvas, Helper panel, plan limits and whether Helper “Ask” is enabled were not observed. Editor-canvas design points are therefore proposals, not observed defects.

Labels used: Observed seen directly in shipped code, docs or screens · Inference my reading of the evidence · Proposal a suggested change. Findings from the rundown are attributed to it unless I re-checked them. One app's behavior (for example Sponsor Desk) is not treated as a platform-wide limitation unless a platform file or doc shows the same thing.

2. Strengths and friction map

Each material finding has a source and a confidence level. Proposals are kept out of this section and appear in section 3. The table below is the short answer to “where can Exotool improve?”. The detailed evidence follows in 2a–2d.

Where Exotool can be improved: at a glance

Severity is my judgment of the harm to users if nothing changes: High blocks or drives users away, Medium slows them or adds risk, Low is polish. “Fix” points to the recommendation in section 3.

2a. Strengths to keep

2b. Friction, by person and journey stage

2b-ii. The journey for three people

2b-iii. Visual design: observed defects and opportunities

Observed defects (editor sign-in page, Expense Splitter sample, element_gallery sample; screenshots of 4 Nov):

• The primary action (“Sign In”, “Log In”) is a thin list row with no fill, so it reads as text rather than a button.
• Labels are about 11–12 px grey, and placeholders are at 35% black. Hierarchy comes only from one bold heading.
• Pinch-zoom is blocked; the page language is unset; the sample inputs have no label elements.
• Placeholder copy (“My Mobile App”, “Hello World!”, “page1”) is visible in a public sample.

Design opportunities Proposal (the editor canvas was not viewed, so these are not defect claims):

• Editor sign-in and project list: a split layout with a live sample app on the right. Project cards with a thumbnail of the last compiled screen, the compile status and “edited by”.
• Palette: grouped by intent (Screens, Content, Forms, Lists, Logic, Live) with icons and a one-line hint. Only valid drop targets light up while dragging.
• Property panel: the 5 most-used fields first; advanced fields in a collapsed section. Inline validation next to the field, using the same words as the Helper card.
• Interaction states everywhere: hover, focus (2 px ring), pressed, disabled and error, with 44 px minimum touch targets in generated apps and 32 px in the dense editor.
• Typography and spacing: 16 px base in apps (14 px in the editor), a 1.25 scale, an 8 px spacing grid, and line length capped near 70 characters for content blocks.
• Mobile use of the editor: a read-only “review on phone” mode (change review strip, preview, comments) rather than full editing on a small screen.

2d. Agents in three roles

Sponsor Desk is used as the running example. Each role applies equally to any Exotool app.

3. Prioritized recommendations

Ranked on user benefit, strength of evidence, reuse of what exists, and ongoing burden. Refinement means it ships within the current design. Extension means it changes the architecture or the data model. Effort is relative: S (small), M (medium), L (large).

#	User and problem	Specific change	Reuses	New development	Expected benefit	Kind	Effort	Conf.
R1	End users who need larger text or use screen readers; agencies with accessibility obligations.	In the generated shell and the editor: allow zoom (drop user-scalable=no and maximum-scale), set lang, render submit links as <button>, add <label for> to inputs, raise placeholder contrast, show a visible focus ring.	The shell template and element templates	Template edits; a check that custom CSS still fits	Removes clear WCAG failures in every app on its next compile	Refinement	S	High
R2	End users on phones; owners who expect “install” and offline use.	Replace <html manifest> AppCache with a web app manifest (name, icons from the existing icon pipeline, theme colour) and a service worker that caches the app shell. Phase 2: queue writes made offline.	The icon generator, the compiled asset list, the per-app preview URL	Service-worker generator; cache versioning per compile. Phase 2 needs sync and conflict rules.	Install prompts and fast reloads in current browsers; “PWA” becomes literally true	Refinement (shell). Phase 2 is an extension.	S–M, then L	High (legacy markup observed)
R3	Novices whose first app looks dated; agencies who restyle every project.	A new “2026” app-level preset built on design tokens: 16 px base text, a 1.25 type scale, a 4/8 px spacing grid, primary, secondary and quiet button styles, hover, focus, disabled and error states, 44 px touch targets, and light and dark modes. Existing presets stay unchanged.	The viewpool preset system; templates	Token CSS layer on top of Framework7 1.4; restyling of about 30 element types	Better first impressions; less per-project CSS; consistent quality	Refinement	M	High on need; medium on scope (Framework7 limits)
R4	Novices facing 45 unlabelled samples.	A “Start from a goal” picker: about 8 curated starters (booking, CRM pipeline, field service, directory, expense split, store, loyalty, internal tool) with screenshots and plain names. Hide test fixtures. Fix showcase samples that open on “Hello World!”. Each starter launches its Helper tour.	Samples, copy project, Helper tutorials engine	Curation, screenshots, a picker page, 2–3 more tours	Shorter time to a first useful app	Refinement	S–M	High
R5	Experts and agencies making many or AI-made edits; novices unsure what a save did.	A “Change review” strip after each save: the elements added, changed or removed (highlighted on the canvas through the Helper bridge), compile status, who made the change (you, Claude, a teammate), and Undo. Keep 20 backups and let a backup be named.	Save and patch summaries, backups and undo, revision checks, Helper highlight and go-to, “Claude:” notices	Summary to canvas-highlight mapping; a longer backup history	Trust in AI and bulk edits; faster recovery; fewer support tickets	Refinement	M	High
R6	Novices fighting layout rules and known defects.	Turn the best-practice list into editor behavior: auto-route connectors and auto-place new activities to the right; block or auto-wrap a link dropped on a page; fix form-field icons and Buttons Row, or hide them until fixed; flag an unconnected symlink live.	Auto Reposition, structural checks already run on save, Helper rules	Editor interaction work	Fewer silent failures; less to memorise	Refinement	M	Medium-high (canvas not viewed)
R7	Agencies and owners worried about risk.	A data-exposure report per compile: which variables reach the device, which flows run on the server, which API endpoints exist, where raw JS or PHP blocks bypass analysis, and which activities lack a session or role check.	Compile facts, the API node list, the Helper rules engine	Report page and a few new rules	A concrete answer to “is this app safe?”; a strong sales asset	Refinement	M	Medium-high
R8	Agencies and clients whose staff work in AI assistants.	Endpoint nodes published as MCP tools and OpenAPI, with app tokens scoped to named endpoints and bound to a user, rate limits and an audit log.	API node, generated call examples, MCP Tokens page, sessions	Token scopes, a tool descriptor generator, audit storage	Each app becomes usable from assistants without new code	Extension (new auth surface)	M–L	Medium
R9	Novices who forget a permission check; owners needing assurance.	Declared access rules on cloud objects (for example “owner may edit”, “role ‘manager’ may read all”), enforced by the compiler on server paths and shown in the R7 report.	Cloud object types, sessions and user types, server placement	Rule syntax, compiler enforcement, a migration default (no rule = current behavior)	Secure by default instead of secure if remembered	Extension	L	Medium
R10	Builders stuck on a compile error or a design question.	Enable Helper Ask, grounded in the diagram, errors and docs. It answers with element links and an optional patch that goes through R5.	Helper Ask box, rules, MCP patch path	Model integration, grounding, cost controls	Help at the moment of need	Refinement plus a recurring cost	M	Medium (current status unknown)
R11	Agencies needing exit options and audits.	Project export: the diagram JSON, assets and the compiled bundle as a download, plus import.	The JSON diagram, the compile output, copy project	Packaging, import validation, licence terms	Reduces lock-in fear in sales	Refinement (commercial decision)	S–M	Medium
R12	Users of real-time features.	Move broadcasts to POST, require a channel key or session server-side, and consider Server-Sent Events for delivery.	Signal and listen elements	Transport change behind the same elements	Safer, faster live updates with no diagram changes	Refinement	S–M	Medium (server not seen)
R13	Owners wanting AI inside their apps.	The server-only ask_model built-in with typed output and spending caps (Agents role 2).	Location model, resources, PHP runtime	Built-in, resource type, metering	AI features without exposing keys	Extension	M	Medium

3b. Steps that widen the moat and make Exotool much more useful

A moat is an advantage that grows with use and that a competitor cannot copy quickly. Section 3's table fixes what users expect. This section is about what could make Exotool hard to replace. One distinction matters:

• Not a moat (but required): a modern theme, install and offline support, version history, export and a security scanner. Competitors already document these (section 2c). They stop Exotool from losing deals, but they will not win deals on their own.
• A possible moat: anything that depends on the compiler understanding the whole app: every screen, every flow, and where each piece of logic and data runs. AI code generators produce ordinary source code; to match this they would need dependable whole-program analysis of code they did not design for it. That is possible, but slow and approximate. This is my inference, not a proven barrier.

The steps build on each other. Each one makes the next more valuable.

Step	What to build	Why it is massively useful to users	What it builds on	Why it is hard to copy, and what could erode it	Copy resistance (inference)
1 Make the compiler's knowledge visible	The change review strip (R5) and the data-exposure report (R7): for every save, show what changed, what runs where, and what data reaches the phone.	A builder can answer “what did the AI just do?” and “is client data exposed?” in seconds, without reading code.	Compile facts, save summaries, backups and undo	Rivals review code diffs (Lovable history, Replit checkpoints). Exotool can explain behavior and data placement. Erosion: rivals adding strong static analysis to generated code.	Medium-high
2 Make safety part of the app model	Declared access rules (R9) checked at compile time. A save, by a person or an AI, that breaks a rule fails like a syntax error and is never published.	Apps are secure by default instead of secure if remembered. Owners can promise clients that an assistant cannot ship an app that breaks its own rules.	Step 1, the compiler, cloud object types, sessions	Bubble, Lovable and Retool have declared rules too. What is uncommon is the compiler blocking a change that breaks them. Erosion: rivals adding pre-deploy policy checks.	Medium
3 Generate behavior checks from the flows	Because each flow is an explicit graph, Exotool can create test scenarios on its own (for example “a non-owner tries to edit, and is refused” or “a save with an empty amount is rejected”) and run them on each compile.	It closes the gap between “it compiles” and “it works”. Users find broken business logic before their clients do.	Flows and conditions in the diagram, Step 2's rules, the debugger runtime	Code tools can write tests, but must first work out the flows from the code; Exotool already has them as data. Erosion: AI test writers improving quickly.	Medium
4 A library of verified parts, with an agency marketplace	Parts (login, booking, payments, sponsor pipeline, maps) that carry their own facts: what data they touch, where they run, which rules they need. The exposure is shown before a part is inserted. Agencies can publish and sell parts.	Novices build real apps from tested blocks. Agencies earn from their best work and build faster.	Extract and insert part, the cluster check, presets, Steps 1–3	This is a network effect: each new part makes the platform more useful, which brings more builders, who add more parts. Erosion: low early on. It needs a critical mass of parts and a good quality bar.	High once it has scale
5 “Assistant-ready” apps by default	Every API endpoint node becomes a typed MCP tool (R8) that runs as a user, obeys Step 2's rules and is listed in Step 1's report. The report tells an owner exactly what an assistant can and cannot do.	Staff can run real business steps from Claude or ChatGPT safely, with no extra code and no extra integration project.	API endpoint nodes, the MCP Tokens page, Steps 1–2	Others expose apps through APIs and webhooks (Bubble, Retool). The edge is the combination: generated tools plus enforced rules plus an exposure report. Erosion: a common standard for agent permissions may arrive.	Medium
6 Offline by design, not by effort	The compiler knows which writes are safe to queue on the device. It could generate offline queues and sync for those writes automatically (R2 phase 2).	Field teams, events and venues with weak signal get apps that keep working, with no special build work.	Device and server placement, the R2 service worker	FlutterFlow documents an offline PWA option, but automatic queueing chosen by the compiler's placement is uncommon in the docs checked. Erosion: offline-first database products.	Medium-high
7 A learning loop from real use	With owners' consent, use anonymous, combined counts of compile errors and Helper card outcomes to improve rules, tours and AI prompts every month.	Help gets better the more people build; fewer users get stuck in the same place.	The Helper rule table (data, versioned), compile reports	A data advantage that grows with usage. Erosion: weak unless usage grows, and it must respect privacy terms.	Grows with scale
8 Make leaving easy, so joining is easy	Full export (R11) and a published app-model format.	It removes the biggest fear of no-code buyers.	The JSON diagram, compile output	This is not a moat by itself. It lowers the price of trying Exotool, so Steps 1–7 reach more users. The compiler, parts and rules stay the reasons to stay.	n/a (adoption lever)

The sequence I would choose: Steps 1 and 2 first, because they turn work you have already done into something users can see and buy. Step 4 next, because network effects take time to build, so the sooner the better. Steps 3, 5 and 6 then grow from the same foundation. Fixing the table-stakes items in section 3 (R1–R4) is still what lets prospects stay long enough to notice any of this.

3c. A working direction: the clickable mockup

To show what these recommendations look like on screen, I built a clickable mockup of the editor and of the Sponsor Desk app it generates: https://exotool-ui-mockup-preview.cyrusprescod.workers.dev/. Each figure below links to the exact screen, so you can try it.

Proposal What it is and is not. It is a design mockup. It is not built on Exotool's code and has not been tested with users. It does use real material from the Sponsor Desk project (revision 25): the element keys, connector conditions, and the code facts from your compile report of 2 November. All sponsor data is fictional.

Every part maps to Exotool. The mockup has 49 labelled parts. 27 use Exotool exactly as it is today, 9 show an existing feature better, and 13 are proposals. Each proposal names the existing feature it builds on. The mockup's Feature map view lists all 49.

How each recommendation shows up in the mockup

Rec.	What you see	Builds on (exists today)	Try it
R1	Text at 200% that reflows; labelled fields; buttons instead of links	Generated viewport, form inputs and buttons	200% text
R2	Install banner, offline banner, “Installable app” setting	App icon, preview build	Open it
R3	Light and dark 2026 theme; a fourth preset in New project	3 theme presets	Open it
R4	Goals that copy a sample	45 system samples, copy project	Open it
R5	Change review with diff, undo and named versions	Save summary, 4 backups, undo	Open it
R6	Palette by intent and search; guided link drop	Element palette; nesting check in save and patch	Editor
R7	Device and server badges; code facts; Data exposure report	Compile-report code facts (since 23 Oct)	Open it
R8	“Offer API endpoints to assistants as tools”	API endpoint node and its call examples	Open it
R9	Read, change and delete rules per cloud object type	Cloud object types, sessions, roles table	Access rules
R10	“Fix with Claude” on a Helper card, landing in Change review	Helper rules, MCP patch	Open it
R11	An “Export project bundle” button only	Diagram JSON, extract part	Open it
R12	Signed-key setting; the live notice	Signal and listen	Live notice
R13	Not shown. AI inside finished apps needs its own design.	–	–

What building the mockup showed. Most of the proposals need no new engine. R5, R7 and R10 reuse data Exotool already produces: the save summary, the compile report and the Helper rules, joined to the MCP patch. R1 and R2 are changes to the generated output, so every app improves on its next compile. The mockup cannot show two things: whether new users read the labels as intended, and whether the PHP server side supports R9 and R12 as drawn. On that basis, the first working slice I would choose is R1 and R2 (output), then R5 with R10 (editor), then R7.

4. Before and after

5. Owner-side scope and cost

Relative estimates only. I don't know your team size, rates or hosting contracts, so no calendar or dollar figures are given. S, M and L compare items with each other.

Assumptions that change cost the most.

• Whether existing apps are recompiled automatically after a platform update, or only when their owners save. Automatic recompiles spread R1 and R2 instantly, but raise regression risk.
• How far Framework7 1.4 can be restyled. If the token layer fights it, R3 grows toward a UI-kit migration (L).
• Who pays model charges: the owner, or customers with their own key.
• How much server-side session and role data is already available to the compiler. This sets the cost of R9.
• How many existing apps use custom CSS or raw JS that depends on today's markup.

Little extra vendor spend, but still development time: R1, R2 phase 1, R3, R4, R5, R6, R7, R11 and R12. All of these are template, editor or report work on infrastructure you already run.

6. The recommendation to lead with in sales

What supports it today. Revision checks refuse stale edits. A backup is made before every save, patch and undo, and one-step undo exists. Compile and structural errors come back with exact paths, and the docs say they are checked before anything is called done. Per-element compile facts show where each piece of logic and data runs. Sponsor Desk, an 18-activity, 6-screen app whose diagram metadata shows it was edited through MCP, compiles with 0 errors on revision 25. All of this is Observed in the MCP tools, the docs and the rundown.

What must exist before you claim the stronger version (“an AI can't ship an unsafe or broken app on Exotool”):

• Declared access rules enforced by the compiler (R9) and the data-exposure report (R7). A clean compile today proves structure, not correct permissions or business behavior.
• Change review in the editor (R5), so the human check is visible rather than implied.
• A modern, accessible, installable shell (R1–R3), so the “safe” app is also one people want to use.
• A published security note on live messaging and file uploads, after you have reviewed the server side (R12).

Thank you for building something with a genuinely different core. I hope this helps you choose what to do next.

Cyrus Prescod