Commercial lessons from building AxipApp and Platfio

The original AxipApp idea was simple: help small and medium businesses get useful iOS, Android, and web apps without paying for bespoke software every time.

The original Platfio idea was also simple: help agencies and digital teams deliver software faster with better tooling and AI-assisted engineering.

Both ideas were true.

Both were incomplete.

For years, we would have just called the process “being a startup”: stay close to customers, ship quickly, learn from the field, and keep tightening the product.

The recent prominence of forward deployed engineering has formalized a lot of that work. It gives a clearer name to the same pattern: create delighted, sticky customers with custom implementations that still remain manageable by the business or agency, then turn what you learn into product feedback.

The deeper commercial lesson was that the hard part was not only building apps, writing code, or automating delivery. The hard part was learning where customer-facing work belonged.

Some FDE work belonged inside the apps themselves: no-code business features, low-code escape hatches, pages, automations, data models, and customer-facing workflows.

Some solutions work belonged around the agency operating system: proposal templates, funnels, onboarding, App Store and Play Store account setup, agents, delivery memory, and handover.

Mixing those together made the product harder to reason about. Separating them made the platform stronger.

That is where forward deployed engineering became useful.

Not as a title borrowed from frontier labs, but as a way of working: get close enough to the customer to see the real workflow, technical enough to build the custom implementation, careful enough that the customer can still manage it after launch, and disciplined enough to feed the product instead of creating a pile of bespoke exceptions.

The platform context made that discipline non-negotiable.

Platfio had to support consultancies, customer applications, release workflows, and agent-assisted operating loops across planning, delivery, support, and handover. These were real production deployments, not toy deployments, so the platform had to absorb field complexity without turning every customer into a special case.

At that scale, a one-off customer workaround is not harmless. It becomes product debt, support debt, deployment debt, and training debt. The work had to turn repeated field reality into reusable capability without making the platform generic.

The commercial engineering work

The work was both customer-facing and deeply technical. I was not just translating requests into tickets. I was working across discovery, architecture, implementation, deployment, adoption, support, and production incident response, then deciding which field lessons deserved to become reusable product infrastructure.

Signal	Evidence
Customer-facing delivery	Led agency and business deployments from discovery through production adoption, including scope, rollout risk, onboarding, handover, and support
Executive and stakeholder work	Worked with agency founders and customer stakeholders to define value cases, priorities, adoption metrics, and implementation tradeoffs
Platform engineering	Turned repeated app, agency, deployment, and agent workflows into reusable product primitives instead of bespoke delivery work
AI deployment	Owned agent workflows across planning, proposal generation, implementation support, support triage, and handover
Operational ownership	Handled production issues across mobile release, store review, backend compatibility, version skew, app configuration, and support handover

Contents

• The commercial engineering work
• The two commercial lanes
• FDE work on apps
• Solutions work with agencies
• The reusable shape
• How the system found its shape
• Deployment is product infrastructure
• The real lesson

%%{init: {'flowchart': {'nodeSpacing': 36, 'rankSpacing': 48}}}%%
flowchart LR
  Field["Field reality"] --> Translation["Commercial translation"]
  Translation --> Apps["App layer"]
  Translation --> Agency["Agency layer"]
  Apps --> Platform["Reusable platform capability"]
  Agency --> Platform

Commercial lane	Examples	Product response
Apps	Products, bookings, pages, automations, customer workflows	No-code features plus low-code extension points
Agencies	Proposals, funnels, onboarding, app store accounts, agents	Operating-system workflows around delivery
Deployment	App metadata, credentials, builds, store review, handover	Managed release infrastructure
Product feedback	Field discoveries, repeated pain, failed abstractions	The product learns from customer work instead of repeating it
Memory	Decisions, artifacts, playbooks, support context	The next similar project starts smarter

The useful FDE move is not to do heroic customer work forever. It is to turn repeated customer work into product capability.

The two commercial lanes

The first mistake is treating all field work as the same kind of work.

It is not.

When a customer says, “I need to sell memberships,” that usually belongs in the app layer. It may become a no-code feature, a reusable primitive, a configuration screen, or a low-code extension.

When an agency says, “I need to turn a sales call into a scoped project,” that belongs in the agency layer. It may become a proposal template, a funnel, an onboarding checklist, an agent workflow, or delivery memory.

Both are customer-facing technical work. They just compound differently.

App work compounds into reusable product capability.

Agency work compounds into a better delivery machine.

Good field work had to do both jobs at once: make the current customer feel like the product was built for them, while leaving behind feedback, tooling, and product memory that made the next customer easier to serve.

The platform needs both.

The hard part was that the same customer conversation could contain both lanes.

A business might ask for a branded app, but the agency delivering it also needed a proposal, asset checklist, store account setup, launch plan, support handover, and a way to remember why certain decisions were made. If we treated all of that as app configuration, the app layer became bloated. If we treated all of it as agency process, the customer-facing product became too thin.

That is where the system started to evolve: not from a grand architecture document, but from noticing which repeated pains belonged inside the app and which belonged around the agency operating model.

FDE work on apps

AxipApp exposed a blunt truth: many customers were not just non-technical. Their support systems were non-technical too.

The person responsible for the project might be a gym owner, clinic operator, marketing manager, front-desk lead, or an “IT person” whose real job was keeping email, Wi-Fi, devices, printers, and basic SaaS accounts working. They understood their business. They did not want to model software primitives. They wanted the app to let customers book, buy, subscribe, check in, receive updates, and trust the brand.

That made the app layer the first FDE surface.

Some of that work needed to become no-code:

• Products and product collections.
• Bookings, classes, subscriptions, locations, staff, offers, content, and forms.
• Navigation, homepage structure, app settings, branding, and business rules.
• Push, email, SMS, chat, customer records, and basic reporting.

No-code mattered because the business user needed to keep operating after launch. If changing a product, service, offer, booking, or announcement required a developer, the platform had not really absorbed the work.

But no-code was not enough.

There also had to be low-code escape hatches for the cases where a serious customer or agency needed more control:

• Code-based pages written in HTML, CSS, JavaScript, and Lit.js.
• Code-based automations written in Node.js.
• Custom integrations and workflow logic that did not deserve to become a global no-code feature yet.
• App-specific behaviour that needed to move quickly without forking the whole platform.

That split was important. No-code handled the repeated business primitives. Low-code handled the edge where the platform needed to stay flexible without turning every request into core product.

The first version of this judgment was not perfect.

It is tempting, especially when trying to move quickly for an agency or customer, to promote too many field requests into no-code features. The problem is that every new global option becomes something the next business has to understand, the support team has to explain, and the deployment system has to preserve across versions.

The better rule became: if a request appeared repeatedly across industries, it probably deserved a no-code primitive. If it mattered deeply to one customer or agency but did not yet have a repeated shape, it belonged in a low-code escape hatch or managed field workflow until the pattern proved itself.

Industry language almost tricked us

Each industry had its own language.

A gym did not talk like a clinic. A clinic did not talk like a cafe. A cafe did not talk like a salon. They used different words for the same underlying concepts: classes, sessions, appointments, services, offers, practitioners, trainers, menus, programs, packages, memberships, deposits, reminders, intake, check-ins, and pickup windows.

The first product instinct was to honour that language by adding more primitives. If gyms asked for programs, add programs. If clinics asked for services, add services. If salons asked for treatments, add treatments. It felt customer-centric.

In practice, it became net negative.

Every new primitive created more UI, more documentation, more support language, more permission rules, more edge cases, more deployment compatibility, and more decisions for the next agency user. Worse, the primitives started to overlap. The product became harder to learn without becoming meaningfully more powerful.

The field work changed our mind. FDEs using the system inside businesses and agencies kept seeing the same pattern: customers needed their language preserved, but the platform did not need a new core model for every word.

The better answer was fewer primitives with more customization, hidden behind layers of UI abstraction. A customer could see the language that made sense for their business, while the platform kept a smaller set of durable underlying concepts.

This changed the product model. What used to feel like a generic “code module” split into more specific surfaces:

• Backend code became a process under automations.
• Frontend code became a builder type under pages.
• Industry-specific language became labels, presets, templates, fields, and workflow configuration on top of shared primitives.

That is a very FDE lesson. The customer vocabulary matters. But if the platform copies every customer noun into the data model, it stops being a platform.

Less choice was often better

The same lesson showed up in low-code.

Agencies said they wanted maximum flexibility. For custom pages, they asked for the ability to use whatever frontend stack they preferred: Vue, React, or other familiar frameworks inside the builder.

That sounded reasonable from a sales perspective. It also created a product architecture problem. The builder, preview, deployment path, security model, app shell, and support experience were not designed to host every frontend framework as a first-class runtime. Trying to support all of them meant pushing square pegs into round holes.

So we stopped pretending the product was framework-neutral.

We made the docs explicit: use Lit.js.

That was commercially uncomfortable. Some agency owners worried about the cost of training their team on a framework they did not already use. We had to explain why the constraint was worth it: fewer runtime surprises, better compatibility with the app architecture, easier support, more reliable previews, and a smaller surface area for agents and humans to reason about.

Among agency users, too much choice was causing real problems. Once the platform became explicit about the supported path, everyone was happier. It reduced debate, reduced broken custom pages, and made the low-code escape hatch feel like part of the product instead of a place where any arbitrary web app could be smuggled in.

Solutions work with agencies

Platfio exposed a different version of the same lesson.

The early instinct was to make agencies more efficient at building software. That sounds obvious. Agencies sell software, scope software, and manage clients through software projects. If AI and better tooling can make engineering faster, the product should help agencies produce more output with the same team.

But embedding with agencies changed the shape of the problem.

The bottleneck was not only code, and it was not only the apps.

It was the operating system around code: how an agency sells the work, translates buyer intent into a plan, protects margin, coordinates delivery, keeps clients confident, hands over the result, and turns the next similar project into something easier than the last one.

Faster delivery broke the old agency math

One of the more uncomfortable discoveries was that making agencies more efficient could reduce their customer lifetime value.

That sounds backwards. Faster delivery should be an obvious win. But many agencies had built their sales and marketing process around a slower, more labour-intensive delivery model. The price, proposal, perceived complexity, client education, milestone structure, and handover expectations all assumed that custom software took a certain amount of time and coordination.

When the platform made implementation faster, it exposed weaknesses upstream.

Some agencies could now deliver the technical work more quickly, but they had not changed how they sold, scoped, or packaged the work. A project that used to justify a larger retainer could suddenly feel smaller to the buyer. A vague proposal that used to be clarified slowly during delivery became dangerous because agents and platform tools could move quickly in the wrong direction. Efficiency improved, but the commercial story did not automatically improve with it.

That forced Platfio to treat sales and planning as product surfaces, not just agency habits.

The plan and proposal tools came from that pressure. They helped agencies turn discovery into structured scope, preserve the buyer’s language, identify assumptions, explain value, and connect the commercial promise to the implementation path. The goal was not only to generate a nicer PDF. It was to protect the agency’s ability to sell valuable work in a world where delivery was getting faster.

Many agencies already have strong sales instincts. They know how to build trust, position value, create urgency, and explain technical work in commercial language. What they needed was a tighter bridge between that commercial language and the delivery system that would now execute much faster.

AI does not remove ambiguity.

It accelerates whatever ambiguity already exists.

That is why Platfio had to move upstream from project execution into the agency layer.

This work looked different from app features. It included:

• Proposal templates that turned discovery into a credible commercial offer.
• Funnels that tracked a buyer from initial interest through scoping and delivery.
• Onboarding workflows for Apple App Store and Google Play accounts.
• Checklists for business details, assets, permissions, store metadata, and launch requirements.
• Agents that could help with planning, proposal drafting, implementation support, QA, and handover.
• Delivery memory so the next similar app did not start from zero.

The product needed to connect the commercial promise to the implementation reality:

1. Capture the buyer’s words.
2. Separate outcomes from implementation assumptions.
3. Turn vague modules into named requirements.
4. Attach acceptance criteria before work begins.
5. Preserve decisions, exclusions, and handover context.

If the product only helped after the sale, it arrived too late. If it only helped sales, it created promises delivery still had to decode. The useful system sat across the transition points.

The war story here was not one dramatic failure. It was the repeated slow failure of context.

A sales conversation would use one language. The proposal would use another. Delivery would discover missing assumptions later. Support would inherit a launched app without all the reasoning behind it. Agents made that more dangerous because they could move quickly through whatever structure existed, including bad structure.

That forced the agency layer to become more explicit. The question was not just “can an agent draft this proposal?” It was “does the proposal carry enough structured context that delivery, QA, launch, and handover can keep using it after the impressive draft is finished?”

The reusable shape

Across both lanes, the same discipline kept appearing.

AxipApp served different industries, but the same app patterns kept appearing.

Gyms needed classes, programs, trainers, memberships, bookings, announcements, content, and check-ins. Clinics needed services, practitioners, intake flows, appointment logic, reminders, and patient communication. Cafes needed menus, ordering windows, pickup details, loyalty, and promotions. Salons needed services, staff, availability, bookings, reminders, and add-ons.

On the surface, those are different worlds.

In the product model, they overlap.

The commercial engineering job is to stand close enough to understand the difference, but far enough back to see the reusable structure underneath:

• Is this a product, service, booking, subscription, segment, location, staff member, offer, or piece of content?
• Does it have availability, capacity, duration, price, tax, renewal, cancellation, or eligibility rules?
• Which decisions should the business control, and which should the platform quietly handle?
• Which industry-specific words can map onto the same underlying primitive?
• Which requests are repeated enough to become product, and which should remain field work?

This is the heart of platform discipline.

If every industry gets its own bespoke model, the platform becomes a folder of one-off apps. Every feature has variants. Every bug has cousins. Every deployment carries special-case logic.

But if the primitives are too abstract, the product becomes elegant and useless. A salon does not want to configure a “resource allocation entity”. A cafe does not want to manage a “transactional inventory surface”.

The answer is shared primitives with customer language on top.

Products. Bookables. Segments. Subscriptions. Content. Offers. Locations. Staff. Customers.

As few as possible, but no fewer than the field required.

The agency side had its own repeating shape:

Discovery. Proposal. Funnel. Onboarding. Store accounts. Plan. Implementation. QA. Launch. Support. Handover.

The solutions job was to keep those layers separate enough to maintain, but connected enough that a real customer journey could move through them without losing context.

How the system found its shape

The system did not start with clean lanes.

The first shape was closer to an app builder with delivery help around it. That was enough to prove that businesses wanted branded apps without owning the whole technical ceremony. But as more agencies came in, the center of gravity moved. The product had to support the people selling, scoping, launching, and supporting those apps, not just the apps themselves.

The product changed in four ways.

First, we became more careful about what deserved to become a configurable app feature. Too many options made the product harder to operate, so repeated patterns became no-code primitives and unusual work stayed in low-code or managed field workflows until the pattern proved itself.

Second, we stopped treating every industry word as a new product model. The product needed to preserve customer language in the UI, but keep the underlying primitives small. Labels, presets, templates, and configuration were better than a new core primitive for every industry noun.

Third, we became more opinionated about escape hatches. Supporting every frontend framework sounded flexible, but made the product harder to support. Lit.js became the explicit supported path for custom frontend work because it fit the architecture and reduced avoidable choice.

Fourth, agency delivery could no longer sit outside the product. Agencies were where ambiguity and commercial pressure entered the system, so plans, proposals, onboarding, agents, and handover had to become part of the platform instead of process sitting beside it.

The tradeoff was speed versus platform discipline. A bespoke fix can make one customer happy today. A reusable primitive can make the next hundred customers easier to serve. The commercial judgment was deciding which kind of speed mattered.

Deployment is product infrastructure

Deployment was where the abstraction had to become operational.

For engineers, mobile release infrastructure is normal: environments, build steps, assets, signing credentials, store records, version numbers, testing tracks, approvals, rollback plans, and release notes.

For non-technical customers, it is alien.

They experience deployment as accounts, forms, warnings, emails, permissions, review delays, screenshots, policy questions, and unexplained rejection risk. Store onboarding is not admin from the customer’s point of view. It is part compliance, part customer success, part release engineering, part documentation, and part emotional support.

That made deployment an FDE problem, not just a DevOps problem.

The platform had to make customer-specific apps repeatable across web, Android, and iOS. App metadata, identifiers, assets, environment values, store accounts, and release state had to be structured rather than scattered. Manual steps had to become internal tools, checklists, or managed field workflows.

The customer should provide business inputs, not technical interpretation.

This same lesson carried into Platfio. Agencies did not need a pile of isolated scripts. They needed a productised path from scoped work to live system, with evidence, artifacts, logs, handover material, and reusable knowledge left behind.

Deployment is not the final technical chore after the product is built.

For app platforms and agency platforms, deployment is part of the product promise.

The real lesson

The biggest commercial lesson from AxipApp and Platfio is that software platforms do not win by making every customer more technical.

They win by translating complexity into usable operations.

For SMBs, that meant turning app architecture, store onboarding, configuration, and deployment into business-friendly workflows.

For agencies, it meant turning sales, discovery, planning, delivery, support, and AI-assisted engineering into one connected operating system.

The pattern is the same:

• Get close enough to see the customer’s real constraints.
• Preserve the customer’s language.
• Find the reusable structure underneath.
• Absorb technical ceremony into the platform.
• Turn repeated field work into product memory.
• Keep the primitives small enough to maintain and expressive enough to matter.

That is what forward deployed engineering is good for.

Not just building beside the customer.

Learning beside the customer until the product knows what the field keeps teaching.