Building a Pay-As-You-Go Product Without a Customer Database
How I architected A La Carte, GroWrk's pay-as-you-go platform, solved for the one thing it couldn't have, employee records, and turned that constraint into the product line that followed.
Context
The subscription that didn't fit
GroWrk's core product is a subscription, priced per workstation, that bundles in a volume of device movements and services. It works well for companies that actually generate that volume. It's a bad deal for a lead who doesn't.
Sales and the CEO kept running into exactly that lead: interested in GroWrk, unwilling to commit to a monthly fee sized for movement they wouldn't use. Their proposed fix was simple to describe and hard to build: let the client pay only for the specific service they need, a pickup here, a shipment there, a device purchased for inventory, without a subscription underneath it. Turning that idea into an actual, structurally sound platform was my job.
The Problem
A workaround held together by spreadsheets
Before A La Carte had a real platform, it wasn't a product. It was a manual process, and a costly one. Customer Success managers were spending an estimated 9 to 10 hours a week per client just keeping A La Carte orders moving, because there was nowhere in the platform for those orders to live. Everything was tracked off-platform, across spreadsheets, described internally as chaos. At least one client depended entirely on a CS concierge because they had no real platform access at all.
The first version fixed the "no platform" problem, but not the experience problem. Beta clients hit specific, avoidable friction: required fields that didn't match the order type, no way to add a product to a purchase order, no visible confirmation that an order was actually paid, no lead-time information on quoted devices, no way to approve a suggested device without leaving the platform. The beta cohort's Customer Satisfaction Score landed at 5 out of 10. That number became the target for the next round of work, not a footnote to move past.
This mattered beyond user comfort. GroWrk built A La Carte specifically to capture price-sensitive leads. A rough first experience risked losing exactly the clients the product existed to win.
Constraints & Complexity
Building a product with no customer database
A La Carte isn't "All In without the subscription fee." It's a different data model.
In All In, a client adds employees, with addresses, before an order can exist. That employee record is the anchor everything else hangs off. A La Carte has no employee step. There was no database of people or places to point an order at, because nothing had been added yet, and by design, nothing was going to be.
On top of that, the CEO set firm boundaries early: products stay price-free to the client, no custom catalog, no employee uploads, limited platform access across the board, no platform fee, strict pay-as-you-go with no credit extended, and no formal SLAs, ETAs instead. The system also needed a reliable way to tell A La Carte and Subscription companies apart inside shared order and payment systems, and a real path for a client to upgrade from one to the other. None of that was optional detail. All of it had to hold together in one coherent platform, not a stripped-down side project bolted onto the real one.
My Role
Architecting the platform,
not the screens
I designed the flow architecture and the structure of the platform itself: effectively a duplicate of GroWrk's core product, with specific sections gated until a client upgrades. I also proposed the core workaround that made the whole thing possible, creating orders without employee records, which wasn't a spec I was handed, it was my own answer to a data-model problem nobody else had solved yet.
I led discovery and framing across V1 and its post-launch enhancements, aligned Engineering, Operations, and Business on the trade-offs this model demanded, and later led the self-service and pricing work in V2, including folding A La Carte pricing directly into the Service Catalog.
Research
Reconciling three different versions of the same idea
Sales and the CEO had one version of A La Carte: pay only for what you use. Customer Success had another: a manual process eating their week. And the platform itself had a third constraint neither of those groups was thinking about: there was no customer data to build on.
Research meant sitting with Customer Success, Product, Finance, and Sales and reconciling all three. CS surfaced the operational pain directly: manual data entry, onboarding confusion, no visibility into device locations, catalog access issues, and real time cost per client. The CEO's constraints came from the business side: keep it MVP, keep it pay-as-you-go, keep the platform fee at zero. Later research into freemium-to-premium patterns shaped how the eventual upgrade nudges got designed, so the upgrade path felt like a natural next step rather than a paywall.
Defining the Model
A gated duplicate, not a stripped-down side product
Rather than bolting pay-as-you-go pricing onto the existing subscription platform, I designed A La Carte as a structurally separate but visually consistent experience: the same platform, duplicated, with specific sections locked until a client upgrades to Flex or All In.
That gating is visible, not hidden. Locked tabs, like Employee Documents, open an upgrade tooltip instead of the feature. A consistent visual marker, an orange arrow, signals throughout the navigation that a given feature needs an upgrade to unlock. Clients see the ceiling. They're just never blocked by it silently.
Key Decisions
1
Designing orders without employee records
2
Turning a data limitation into an upgrade incentive
Since A La Carte clients had no pre-registered employees, I proposed capturing the shipping address only at the moment of order, instead of requiring the upfront employee-management step every other GroWrk order type depends on.
The trade-off is real. Without a persistent address on file, clients re-enter shipping information on every order, and that repetition carries some risk of error on repeat orders that hasn't been formally quantified yet. What it bought in return was a true zero-setup entry point: a client could place their first order without committing any data upfront, which is exactly what a pay-as-you-go product needs to actually feel pay-as-you-go.
Here's the part worth sitting with. The platform's inability to store shipping addresses wasn't hidden or apologized for. It was framed, deliberately, as a reason to upgrade: addresses only persist once a client moves to Flex or All In, so every re-entry is a small, felt reminder of what the next tier buys them.
The order matters here. The technical limitation came first, address storage genuinely wasn't part of A La Carte's data model. The upgrade framing was the response to that limitation, not the reason it existed. That's an honest distinction, and it's also the more interesting design decision: instead of treating a constraint as something to minimize, I treated it as something to mean something.
3
Designing against a real number, not an assumption
A La Carte's first client beta didn't produce vague sentiment. It produced a 5 out of 10 CSAT and a specific list of what was actually broken: mismatched required fields, no way to add a product mid-order, no confirmation an order was paid, no lead-time visibility, no in-platform way to approve a quote. Every one of those got a named fix: adjusted field logic by order type and country, an Add Product flow for purchases, an Order Paid indicator, lead-time display, and an in-platform approval flow with notifications.
Improving on that 5/10 baseline was set as an explicit success criterion, not a hoped-for side effect.
Validation
What real usage showed, not a lab study
This wasn't a multi-session usability study like Service Catalog's. It was something more honest in its own way: real, paying beta clients using a live product and reporting real friction, measured against a real number instead of a general impression. The 5/10 CSAT gave the team something concrete to design against, and the fixes that followed were built to answer specific complaints, not hypothetical ones.
Outcome
What shipped, and what it made possible
V1 shipped and is live. It replaced a fully manual, spreadsheet-based workaround with a self-service platform, captured revenue immediately at order creation with no credit extended and no accounts-receivable risk, and gave the business a reliable way to tell A La Carte and Subscription companies apart inside shared systems.
V2 is in progress, extending V1 toward a more complete self-serve experience and folding A La Carte pricing directly into the Service Catalog.
The clearest measure of impact isn't a usage metric. It's this: A La Carte's existence directly created the need for Flex, a hybrid of A La Carte and All In pricing logic built specifically because A La Carte proved the demand existed. Without A La Carte, Flex wouldn't exist. A product built to capture leads the subscription model was losing ended up generating a second product line entirely.
Reflection
What I'd do differently, and what's next
The most durable lesson here wasn't about the order flow. It was that a real limitation, framed honestly, can become a business lever instead of something to apologize for. Not every constraint needs to be engineered away. Sometimes the better move is deciding what a limitation should mean for the business, and designing around that meaning instead of hiding it.
If I kept going, I'd want a confirmed post-enhancement CSAT number to see whether the fixes actually moved the 5/10 baseline, and I'd want to quantify the real risk the no-employee-record constraint creates (error rate, incomplete orders, support volume) instead of leaving it as an open question. I'd also want to track how many A La Carte clients actually convert to Flex or All In, to see whether the address-reentry-as-incentive reframe is working the way it was designed to.