Case Study · Digital Platform & Business-System Architecture
MyEnergyBiz
Turning a lead-selling concept into the architecture for a vertical customer-acquisition platform.
MyEnergyBiz was conceived around a specific market problem: energy advisors need customers, but access to targeted lead inventory — and the systems required to work those opportunities — can be fragmented.
The project began with a simple commercial concept and expanded into the architecture for inventory, geography, package selection, customer workflow, purchase intent, administration and future marketing infrastructure.
Project Snapshot
- Product
- Customer-acquisition platform for energy advisors.
- Initial commercial offer
- 100 historical solar-interest leads plus the Community Solar Advisor Outreach Playbook.
- Price
- $50 one-time. No subscription required for this offer.
- Primary targeting model
- Geography-based lead selection — state, county, city and ZIP.
- Current stage
- Version 0.1 — staged implementation, in active development.
- Engagement scope
- Product strategy, commercial architecture, data / inventory modeling, geography architecture, customer workflow, purchase-intent architecture, administrative infrastructure, responsive product experience and staged roadmap development.
Business opportunity
The Starting Point Wasn’t a Website. It Was a Business Model.
The core concept was straightforward enough to describe in a sentence: sell targeted historical solar-interest leads to energy advisors who need customers. Advisors are not short of ambition; they are short of qualified conversations in markets they can actually serve.
But a usable business could not stop at upload spreadsheet → display leads → collect money. That sequence describes a transaction, not a product. Before any interface could be designed, the model had to answer a set of questions that were commercial and structural rather than visual.
Those questions are the reason this engagement became product and business architecture first, and an interface second.
The questions the model had to answer
What exactly is being sold?
How should it be packaged?
How should geography work?
How should availability be determined?
How should buyers move from interest to selection?
How should inventory eventually be allocated?
How should sensitive lead data be handled?
How should administration work?
What future services should the architecture accommodate?
Product model
Simplify the Offer Before Expanding the Platform.
Earlier iterations of the concept carried more product complexity than a first release could justify. That complexity was deliberately reduced into a single, legible offer: one package, one price, no subscription.
Lead & Script Package
Available today- 100 historical solar-interest leads in a selected target area
- Community Solar Advisor Outreach Playbook
$50 one-time purchase
The same package price applies regardless of ZIP, city or state. Pricing does not fluctuate by territory, which removes a negotiation the product does not need.
Leads + Marketing Package
Coming soonA monthly subscription combining lead supply with marketing and automation tooling. It is presented on the platform as a future package and is not available for purchase. It is documented here because the architecture was shaped to accommodate it, not because it exists.
The platform states its own status in the interface: the available package carries a note that secure checkout is being finalized, and the subscription tier is rendered as a disabled “Coming Soon” card rather than a purchasable option.
Geography as architecture
The Product Is Inventory. Geography Determines Whether It Is Useful.
An energy advisor does not need “100 leads.” They need 100 leads in a market they can work — where they are licensed or contracted, where they can realistically follow up, and where a community-solar program is relevant. A hundred records in the wrong state are not a cheaper version of the product. They are not the product at all.
That single observation moved geography out of the search box and into the product model. Territory is not a filter applied to inventory; it is part of the definition of what is being sold.
So the architecture had to carry geography at several levels at once, and reconcile the level the buyer thinks in with the level the data is recorded at.
Read this screen carefully. It demonstrates geographic inventory architecture and the selection interface — not inventory volume. The public marketplace is not populated with live sellable inventory today; the capture shows zero territory segments and an explicit onboarding state, which is the platform’s honest current position rather than a rendering artefact.
What geography has to resolve
- State
- The outermost boundary. Advisors are frequently licensed, contracted or practically limited to particular states, so state is the first filter rather than a label.
- County
- The level at which utility territory and community-solar program relationships tend to become meaningful, and a practical unit for describing a working area.
- City
- How advisors usually describe the market they actually work, which makes it the vocabulary the interface has to speak.
- ZIP
- The unit the underlying lead records carry, and therefore the level at which inventory is counted and a package is judged sufficient.
- Utility / market relationships
- Where applicable, program and territory relationships sit alongside the political geography, because eligibility does not always follow city limits.
- Availability & sufficiency
- Geography is only useful if the system can answer whether a selected area holds enough inventory to constitute a package at all.
Inventory architecture
A Spreadsheet Is Not an Inventory System.
A file of lead records can be sold once. It cannot be operated. The moment a second buyer, a second supplier or a second territory enters the picture, the questions stop being about presentation and start being about state: what is available, what has been committed, what should never be contacted, and what came from where.
So the project moved toward a unified inventory model. The layers below describe the structure the platform is built around. They are documented here as architecture — foundations that support the product as inventory is onboarded — rather than as a claim that every layer is a finished, exercised feature today.
Supplier ingestion
Lead records arrive from outside the platform in whatever shape the source keeps them. Ingestion has to be a defined intake step with a record of where a batch came from, not a manual paste into a table.
Normalisation
Addresses, contact fields and geography are reconciled to a consistent internal shape so that one ZIP means one ZIP regardless of which supplier supplied it.
Geography resolution
Each record is placed within the state / county / city / ZIP hierarchy, which is what allows a buyer to select a territory and the system to answer whether that territory holds a package.
Inventory status
A record is not simply present or absent. It is available, withheld, or already committed — a distinction that matters the moment two buyers are interested in the same area.
Quality & status concepts
Historical interest data varies in usefulness. The model carries the notion of record condition rather than treating every row as equivalent.
Suppression & deduplication
The same consumer can appear in more than one source, and some contacts must not be worked at all. Suppression and deduplication are integrity requirements, not optimizations.
Reservation & allocation
Selling the same hundred records twice would be a product failure. The foundation exists to reserve inventory against a selection and allocate it on fulfillment.
Administrative visibility
Whoever operates the marketplace has to be able to see what inventory exists, where it came from and what state it is in — otherwise the operator is guessing.
A note on sensitive data
Lead records describe real people. That makes privacy an architectural requirement rather than a policy page: personally identifiable lead data is held encrypted, and deduplication and suppression exist so the same consumer is not worked repeatedly or contacted when they should not be. The specifics of that implementation are deliberately not documented here, and no consumer data appears anywhere in this case study.
Customer journey
Turn Inventory Logic Into a Customer Experience.
Everything structural about the model has to arrive at the buyer as an ordinary sequence of decisions. The platform expresses it as four steps, in the order the information becomes relevant.
The published workflow states its own limits: the platform tells the visitor that secure checkout is being finalized and that a selection can be browsed, chosen and saved in the meantime.
Choose Package
The Lead & Script Package is selected as a defined product with fixed contents and a flat price, rather than configured from a menu of options.
ImplementedSelect Target Area
The buyer narrows to the geography they actually work. This is the decision that determines whether the product is useful to them.
ImplementedReview Available Inventory
Availability is presented before commitment, so the buyer understands what the selected area holds rather than discovering it afterwards.
ImplementedComplete Purchase
The final step is a secure one-time payment. This is the step that is still being completed — selection can be made and saved, but checkout is not yet operational.
Checkout in development
To be precise about it: the selection and purchase-intent architecture exists and can be used. Final secure checkout is not yet operational, and this case study does not represent completed transactions as an operational capability.
Purchase configuration
The Interface Has to Represent the Commercial Rules.
A configurator is where business rules become visible. Each step in this sequence exists because a commercial decision was made first — the interface is the consequence, not the design.
This is current evidence of product architecture and purchase configuration. It is not evidence of completed payment processing, and no transaction volume is claimed.
- Flat-rate package architecture
- Because price does not vary by territory, the configurator never has to quote. It confirms a known price, which keeps the interface to four steps instead of a pricing negotiation.
- Geography selection
- The target area is captured as a structured selection against the geographic hierarchy, not as free text for someone to interpret later.
- Availability verification
- The workflow includes an explicit availability step, because a package is only a package if the selected area can supply it.
- Bundled playbook content
- The outreach playbook is shown as part of what is included, with its sections visible, so the buyer can see the deliverable is more than a list of records.
- Saved purchase-intent state
- A selection can be saved and returned to. Intent is persisted as state in the system rather than lost when the tab closes — which is also what makes checkout an addition rather than a rebuild.
Product content
The Deliverable Isn’t Only the Leads.
Records alone transfer a problem rather than solving one. An advisor who receives a hundred historical contacts still has to decide how to open the conversation, what to do when someone replies, how quickly to respond and when to stop. That is why the product pairs lead inventory with the Community Solar Advisor Outreach Playbook.
The playbook is presented on the platform as a set of practical sections rather than a single attachment — a quick-start guide, an initial outreach campaign, response handling, speed-to-contact and follow-up guidance among them, each carried as its own versioned module.
Treating guidance as structured product content has consequences beyond tidiness. A module can be revised without reissuing the whole document, a buyer can be shown what is included before purchase, and the content can later be delivered inside the platform rather than handed over as an unstructured file. The scripts themselves are proprietary and are not reproduced in this case study beyond what the platform already shows publicly.
Operating side
A Marketplace Needs an Operating Side, Not Just a Customer Side.
Customer-facing screens are the half of a platform that gets photographed. The other half decides whether the business can actually be run: someone has to bring inventory in, know where it came from, keep suppression current, see which selections are outstanding and tell whether the system is healthy.
The administrative foundation was developed around the domains below. Product architecture, on this project, explicitly included the operator’s workflow alongside the customer’s — because a marketplace that cannot be operated is not finished, however well the storefront presents.
- Inventory
- What records exist, in which territories, and in what state.
- Imports
- Batches brought into the platform, with a record of the intake itself.
- Suppliers
- Where inventory originates, so provenance is attributable rather than assumed.
- Customers
- Advisor accounts and the relationship the platform holds with each.
- Orders & purchase intents
- Selections made, saved and — once checkout completes — fulfilled.
- Suppression
- Contacts that must not be worked, maintained centrally rather than per batch.
- Operational health
- Whether the moving parts of the platform are behaving as expected.
- Settings & activity
- Configuration of how the marketplace behaves, and a trail of what changed.
No administrative screens are shown. The operating side sits behind authentication and would expose supplier and consumer information, so it is described here rather than illustrated. This section documents architecture; the corresponding tooling is a foundation being built out alongside inventory onboarding, not a completed product surface.
Staged implementation
Build the Foundation Before Pretending the Roadmap Is Finished.
MyEnergyBiz is at version 0.1 and in active development. The three panels below are the most important part of this case study: they separate what exists, what is structurally in place, and what is not operational. Each state is named in writing and carries its own icon, so the distinction does not depend on color.
Implemented
Built and in place on the live platform today.
- Public product positioning for the energy-advisor market
- Package architecture presentation — available offer alongside a clearly marked future tier
- Flat-rate pricing presentation, uniform across every territory
- Geography selection interface with state, county, city and ZIP search
- Published four-step customer workflow
- Multi-step purchase configurator: package, geography, availability, review
- Outreach playbook expressed as versioned product-content modules
- Saved package selection — purchase intent captured as state
- Account entry points and authentication foundations
- Responsive product experience across phone, tablet and desktop
- Honest in-product status disclosure about checkout and inventory
Architectural foundation
Infrastructure, models and workflows built to support later functionality. Structurally in place — not a finished, exercised feature.
- Unified lead inventory data model
- Supplier ingestion and normalisation structures
- Geographic hierarchy resolution across state, county, city and ZIP
- Availability and package-sufficiency checks
- Reservation and allocation foundations
- Suppression and deduplication foundations
- Encrypted handling of personally identifiable lead data
- Customer and account architecture
- Commerce foundation for one-time purchase completion
- Administrative and operational infrastructure
Planned / in development
Not operational. Listed so the roadmap is legible — not so the platform appears finished.
- Final Stripe checkout and payment completion
- Populated production inventory in sellable territories
- Leads + Marketing subscription package
- Marketing services
- SMS campaigns
- Email campaigns
- GoHighLevel integration
- CRM integrations
- Customer analytics
- Marketing automation
- Advanced packages
Nothing in the third column is described anywhere on this page as working. Accuracy about a platform in development is worth more than the appearance of a finished one — and it is the same discipline a client should expect applied to their own project.
Responsive product experience
Product Architecture Still Has to Work on a Phone.
Energy advisors are field operators. A platform they might open between appointments cannot treat the phone as a reduced version of the desktop product.
On a narrow viewport the positioning stays intact rather than being trimmed to a headline: the market statement, the plain description of what the platform does and the four supporting propositions all survive the fold change, stacking into a readable column instead of collapsing into an accordion. Navigation condenses to a single menu control so the primary path stays visible, and the two conversion actions — browsing lead packages and learning how the model works — remain stacked, full-width and in the same order of priority they hold on desktop.
The configuration and geography steps carry the same treatment, because the decision a buyer makes does not get simpler on a smaller screen.
No usage claim is attached. We have no measured share of mobile traffic for this platform, so none is stated. The mobile treatment reflects how the intended user works, not a statistic.
Website vs. Business System
When a Website Becomes Business Infrastructure.
A conventional website is not a lesser thing. It is a different thing. Its job is to organize information, establish credibility and move the right visitor toward the right next action — and when a business depends on being found, understood and contacted, that job is strategically decisive. The Pinnacle Kustom Automotive case study on this site exists precisely because a well-architected website was the correct answer to that business problem.
MyEnergyBiz asked a different question. The value was not going to be delivered by a page. It was going to be delivered by a product that had to hold data, know what inventory existed, understand where that inventory was located, decide whether a request could be satisfied, remember what a buyer had selected, and give the operator a way to run the whole thing. At that point the deliverable stops being a website with a form on it and becomes business infrastructure with an interface attached.
The distinction matters when scoping work. Different problems need different solutions, and the expensive mistake is not choosing the smaller one — it is choosing without knowing which one you are in.
What a website has to get right
- Organize information so a visitor understands the offer
- Establish credibility and positioning
- Present services in a defensible hierarchy
- Route the right visitor to the right next action
- Perform on real devices and in local search
What MyEnergyBiz additionally required
- Persistent data that has to stay correct over time
- Inventory logic, availability and allocation rules
- Account and session state
- Geographic structure from state down to ZIP
- Package and pricing rules expressed in the interface
- An administrative side for the people running the operation
- Transactional foundations for taking money safely
Development Approach
Strategy-Led. Technology-Enabled.
Modern AI-assisted development platforms and tooling were used throughout this project. They helped increase production efficiency and shorten the distance between a product decision and a working implementation — which is what allowed a single commercial concept to be taken as far as data modeling, geographic structure, a purchase configurator and an administrative side within one engagement.
AI accelerated production. Product strategy, architecture, commercial rules, implementation decisions and QA remained directed around the business model.
None of the decisions that define this platform were produced by asking a tool for a lead-generation website. Reducing the launch offer to a single flat-priced package, deciding that geography had to be part of the product model rather than a filter on top of it, unifying inventory into one model instead of a stack of imports, separating real inventory from test data, choosing to disclose “coming soon” states in the interface instead of implying availability — those are commercial judgements made against the business, and they are the part of the work that is being represented here.
Iterative Product Development
The Architecture Evolved as the Business Model Became Clearer.
Product work of this kind is not a single specification handed to a build. The model was revised as its commercial consequences became visible, and the architecture was revised with it. These are the changes that shaped what exists today.
- 01
The initial package architecture was simplified
An earlier, more elaborate offer structure was reduced to one clearly purchasable package so the platform could launch with something a buyer could actually understand and complete.
- 02
Inventory logic was unified
Rather than treating each supplier file as its own island, lead data was consolidated toward a single inventory model with consistent geography, status and identity handling.
- 03
Real inventory was separated from test and synthetic data
Development and demonstration records had to be structurally distinguishable from sellable inventory, so that nothing seeded for testing could ever be presented or sold as real.
- 04
Administrative visibility was built
Operating a marketplace requires seeing what has been imported, what is available, which supplier it came from and what condition it is in. That surface was added as part of the foundation, not deferred to later.
- 05
Purchase-intent foundations were added
Buyers can choose a package and a target area and have that selection persist before payment is possible, which separates the commercial configuration problem from the checkout problem.
- 06
The product was rebranded around the energy-advisor market
As the model sharpened, positioning moved toward the professional audience that actually buys lead inventory and outreach guidance, rather than a general consumer framing.
- 07
Current functionality was separated from roadmap modules
Marketing, automation and analytics are shown as forthcoming, in the platform itself as well as here, so no visitor can mistake a roadmap module for an operational one.
Engagement Scope
What Was Built and Directed.
Product & commercial strategy
- Business-model definition for a lead-inventory product
- Package architecture and simplification of the launch offer
- Flat-rate pricing model and its interface consequences
- Geography as part of the product rather than a filter
- Roadmap sequencing for the subscription-based marketing package
- Positioning around the energy-advisor market
System architecture
- Unified inventory data model
- Supplier ingestion and normalisation structure
- Geographic hierarchy from state to ZIP with market relationships
- Inventory status, availability and allocation foundations
- Suppression and deduplication concepts
- Encrypted handling of sensitive contact data
- Administrative data surfaces
Customer experience
- Four-step customer workflow from package to purchase
- Purchase configurator across package, geography, availability and review
- Availability verification in the selection path
- Saved purchase-intent state
- Product-content structure for the outreach playbook
- Honest in-interface disclosure of what is not yet live
- Responsive behavior down to narrow mobile widths
Implementation direction
- Application implementation direction and sequencing
- Separation of real inventory from test and synthetic data
- Iterative review of the model against the interface
- QA of workflow, geography and status presentation
- Decisions about what to ship, what to found and what to defer
Measurement Status
What This Case Study Proves Today.
MyEnergyBiz is a platform under development. That makes the boundary between demonstrated capability and commercial outcome unusually important, so it is stated rather than left to inference.
- Product strategy for a commercial concept
- Commercial modeling of packages, pricing and availability
- Application architecture beyond page-based websites
- Inventory and geographic data architecture
- Customer workflow and purchase-configuration design
- An administrative and operational foundation
- Staged product development with honest status reporting
- Product-market fit
- Revenue performance
- Customer-acquisition economics
- Subscriber retention
- Transaction volume
- Marketing performance
No figure appears on this page that the platform has not yet produced. When the product is operating and there is real performance data, it can be added here — and it will be stated with the same discipline.
Sometimes the Business Needs More Than a Website.
MyEnergyBiz began as a commercial idea — sell targeted lead inventory to people who need customers. Making that idea usable required product architecture, inventory architecture, workflow architecture and an application to hold all of it.
Your business may need a website. It may need a workflow, an integration, a platform, or some combination of the three. The first step is not choosing a technology. It is understanding the business requirement well enough to know what you are actually building.