'Full-Stack' Isn't the Full Stack: Everything That Goes Into a Product

What this is. Opinion + Experience + Fact (40% opinion · 15% experience · 45% fact). Written in collaboration with AI — I discuss, I do not outsource.

"Full-stack" names a slice of one product's build. The real stack it takes to build and run a product is far bigger — even for pure software, and a superset once hardware is involved. This is the map: every layer, the keywords to research each one, and a tested prompt to map your own product. Part 1 of the AI Builder series.

There is a comfortable myth that software is the simple side and hardware is the hard one. It is wrong in both directions. "Full-stack" — frontend, backend, database — was coined for the web, and it describes only the build of one kind of product. The moment you have to actually ship, sell, charge for, tax, support, and keep a product compliant, the stack is enormous — and that is true before a single physical atom is involved.

So this piece is a map, not a manifesto. It is not about mastering any of these layers — no one masters all of them. It is about awareness: knowing that each layer exists, enough to give AI real context, verify what it returns, and know when to bring in an expert. To make it usable, every section below lists the keywords you would actually search to go deeper, and at the end there is a single tested prompt that maps your product's full stack for you.

One caveat up front: this is a core map, not a complete checklist. Every industry and product adds its own layers — a regulation, a channel, a consumable, a tool. If yours has one this misses, that is the point, not a flaw: the real stack is deeper than any single list.

---

1. Software was never simple

Start with a pure SaaS — no hardware anywhere. "Full-stack" covers a handful of build layers. But a real software product is already this deep on the build side:

Build layer (software)	What it is	Research keywords
Product and UX	The problem, flows, and interaction design	jobs-to-be-done · product discovery · UX flows
Frontend	The interface people touch	frontend architecture · React/Next.js · web accessibility
Backend and architecture	Logic, APIs, multi-tenant design	API design · multi-tenant SaaS architecture · microservices
Data	Schema, caching, search, backup and recovery	database schema design · Redis caching · backup and recovery
Scale and DevOps	Cloud, CI/CD, observability, uptime	CI/CD pipeline · Kubernetes · observability (logs, metrics, traces)
Security	Auth, encryption, vulnerability management	OWASP Top 10 · SOC 2 · DevSecOps
Integrations	Third-party APIs, webhooks, SSO	webhooks · OAuth/SSO · API integration patterns
AI layer	Models, inference, evaluation, guardrails	LLM inference · RAG · model evaluation
QA	Test automation and release management	test automation · end-to-end testing · feature flags
Distribution	App stores, signing, staged rollout, updates	app store submission · app signing · staged rollout

And then the product has to be run — the half people wave away as "operations," which is a wall of government-enforced complexity:

Operate layer (any product)	What it is	Research keywords
Positioning and brand	Who it is for, and the message	positioning · value proposition · brand messaging
Marketing and SEO	Demand, content, being found	SEO · generative engine optimization (GEO) · content marketing
Website and conversion	Funnel, landing pages, first-visit to lead	conversion rate optimization · landing page · funnel analytics
Onboarding and activation	Guide new users to value; cut time-to-value	user onboarding · activation · time-to-value (Pendo/Appcues)
Analytics and behaviour tracking	Where users come from and what they do	GA4 · Amplitude/Mixpanel · CDP (Segment) · session replay
Sales	Pipeline, demos, pricing	sales pipeline · SaaS pricing · CRM
Billing and payments	Subscriptions, PCI, fraud, chargebacks	payment gateway · PCI DSS · chargeback prevention
Tax	Where you owe, and how much, per jurisdiction	sales-tax nexus · VAT OSS · GST / digital services tax
Finance	Revenue recognition, unit economics, cash flow	ASC 606 revenue recognition · CAC/LTV · SaaS unit economics
Support and success	Help, onboarding, retention, churn	customer support · onboarding activation · churn reduction
Legal and privacy	Data protection, terms, IP	GDPR · CCPA/CPRA · terms of service
Accessibility	Usable by everyone, and required by law	WCAG 2.2 · Section 508 · accessibility audit
Returns and refunds	Cancellations, prorations, refund accounting	refund policy · proration billing · dunning

Sales-tax nexus alone is dozens of US jurisdictions with different rules; sell into the EU and you add VAT, into India GST, and some countries tax digital goods from the very first sale. That is one row of the table.

And most of that operate stack you do not build — you buy it and wire it together: GA4 for acquisition, Amplitude or Mixpanel for product behaviour, a CDP like Segment to move the data, a helpdesk for support, a CRM for sales, a billing engine, a tax engine. Choosing and integrating that tool stack is a discipline of its own — build-vs-buy: buy the commodity systems of record, build only the workflows that are your edge, and integrate the rest. (keywords: martech stack, build vs buy SaaS, customer data platform, iPaaS integration)

▸ First principle. "Full-stack" is only the build of one product — a real product also has to be sold, paid for, taxed, supported, and kept compliant in every market it touches.

2. A connected product is that stack, plus the physical world

Now make it a device. The mistake is to think hardware replaces the software job. It does not — a connected product still has a cloud, an app, a backend, and every operate layer above. It adds a physical stack on top:

What hardware adds	What it is	Research keywords
Industrial and mechanical design	Form, structure, tolerances, ergonomics	industrial design · design for manufacturing (DFM) · GD&T tolerances
Materials, thermal, sealing	Physics you cannot redeploy	material selection · thermal management · IP rating / sealing
Electronics and power	PCB, schematic, battery, EMC	PCB layout · power electronics · battery management system
Sensors and actuators	How it perceives and acts	sensor selection · actuator control · sensor fusion
Firmware and control	Logic on the device, close to the metal	embedded firmware · RTOS · firmware OTA
Connectivity	Radio, antenna, protocols	BLE / Wi-Fi / cellular · antenna design · MQTT
Prototyping and validation	Concept to production, in stages	EVT DVT PVT · design validation testing · reliability testing
Sourcing and supplier qualification	You do not just "buy parts"	PPAP · incoming quality control (IQC) · second-source component
Manufacturing and yield	A line that builds ten thousand repeatably	contract manufacturer · factory test jig · manufacturing yield
Shipping and logistics	Size and weight are a design input	dimensional weight · dangerous goods shipping (IATA) · cold chain (GDP)
Certification, per country	A market-access gate in every country	CE marking (RED/LVD) · FCC · UL / CCC / PSE / BIS certification
Field service and warranty	Repair, spares, RMA once it ships	RMA process · field service · warranty management

Two of those deserve a second look, because they surprise software-native builders. Shipping is a design constraint: carriers bill dimensional (volumetric) weight — length × width × height ÷ a divisor — and charge the greater of that or actual weight, so a product may have to be redesigned to fit a pallet, and anything flammable, pressurised, or with a battery falls under dangerous-goods rules. Certification is not one stamp: the same device needs CE in Europe, FCC and UL in the US, CCC in China, PSE in Japan, BIS in India — each its own testing, technical file, and audit.

▸ First principle. Hardware is not a different job from software — it is software's whole job, plus a physical one bolted on top.

3. Many devices add a recurring chain

There is one more layer that a pure "electronics" view misses entirely. Many devices carry a recurring, non-electronic input — a consumable, a chemical, a gas, a biological reagent — and that input is a second product with its own sourcing, qualification (often chemical, food, or bio analysis), and compliance regime, frequently from a separate supplier.

Device	Recurring input	Compliance keywords
Coffee / espresso machine	Beans or pods	food-contact materials · NSF/ANSI · food safety
Beverage dispenser	Syrup, CO₂, water filters	NSF/ANSI 18 · HACCP · food-grade tubing
Printer	Ink / toner / cartridge	REACH · RoHS · safety data sheet (SDS)
Glucose monitor / CGM	Test strips / sensors	ISO 13485 · IEC 62304 · MDR/IVDR · ISO 10993 biocompatibility
IVD / lab analyzer	Reagents, assays, controls	EU IVDR · CLIA · ISO 15189 · cold chain
Water purifier / RO	Filter and membrane cartridges	NSF/ANSI 42/53/58 · WQA
EV charger / energy storage	Battery cells	UL 2271/9540 · IEC 62133 · UN 38.3 (transport)
3D printer	Filament / resin	REACH · RoHS · SDS · ventilation

For many of these, the electronics and firmware is the cheapest recurring part. The consumable, its qualification, and its regulation are the real ongoing business.

▸ First principle. The consumable is a second product, with its own supply chain, qualification, and rules — miss it, and you have priced only half the business.

4. The four dimensions that hide inside "hardware"

Even within the build, four disciplines carry most of the risk, and none of them is electronics or code:

Supplier verification. Before a part ships in volume it goes through qualification — PPAP, first-article inspection, incoming quality control — plus supplier audits and a second source for anything critical. (keywords: PPAP, first article inspection, supplier audit)

Manufacturing scale-up. POC to EVT to DVT to PVT to mass production, with yield ramping toward 90–95%. A prototype that works by hand is not a product a line can build. (keywords: production ramp, DFM, first-pass yield)

Design-for-shipping. Dimensional weight, packaging engineering, hazmat classification, and cold chain — the physics and economics of getting the thing to a customer intact and affordably. (keywords: dimensional weight, packaging engineering, dangerous goods classification)

Global certification. Market-access approval, country by country and domain by domain. (keywords: global market access certification, CE FCC UL CCC BIS, regulatory technical file)

▸ First principle. The parts most likely to blindside a builder are the ones that are neither software nor a schematic — supply chain, manufacturing, logistics, and regulation.

5. Map your own product — the prompt

You do not internalise all of this by reading a list. You do it by mapping your product against it. Here is a prompt built for exactly that — self-contained and tested to produce a specific, useful map rather than a generic essay. Paste it, fill in the one bracket, and read the result as a terrain map of the rooms you will have to walk into:

You are a senior product architect and operator who has taken BOTH pure-software
and connected-hardware products from idea to market. I am building:
[describe your product in 2-4 sentences: what it is, who it is for, whether it is
software-only or a physical/connected device, and any consumable it uses].

Map the FULL stack it takes to BUILD and RUN this product. Skip what genuinely
does not apply, and say why. Cover:

BUILD - software: product/UX, frontend, backend and architecture, data (schema,
caching, backup), scale/DevOps, security, integrations, AI, QA, distribution.
BUILD - physical (only if a device): industrial/mechanical design, materials and
thermal, electronics/PCB/power, sensors/actuators, firmware, connectivity,
prototyping (EVT/DVT/PVT), DFM, sourcing and supplier qualification,
manufacturing and yield, reliability.
CONSUMABLE (if any): its sourcing, qualification/testing, and compliance.
OPERATE: positioning, marketing/SEO, website/conversion, analytics, sales,
onboarding, billing and payments (PCI), tax (nexus/VAT/GST), finance and revenue
recognition, support, success/retention, legal/privacy (GDPR/CCPA), returns/RMA.
SHIP and COMPLY (if physical): packaging and design-for-shipping (dimensional
weight, hazmat, cold chain), logistics, and per-country certification
(CE, FCC, UL, CCC, BIS...).

For each layer that applies, give me:
1. the single most important decision at that layer,
2. the most common way teams get it wrong,
3. one question I must be able to answer before I commit,
4. 3-5 search keywords to research it further.

Be specific to MY product. Then flag the THREE layers most likely to blindside
me, and the layers where you (the AI) are least reliable for my case.

Read the output as a starting map, not gospel — the layers it flags as risky are the rooms to visit next, and most of them are future chapters in this series.

▸ First principle. You cannot cover a stack you cannot see — so the first, cheapest move is always to make the whole stack visible for your product.

---

"Full-stack" was never wrong; it was just a smaller word than the job. A software product is already a deep stack of build and business layers, most of them enforced by governments. A connected product is that same stack, plus a physical one, plus — often — a recurring chain of its own. No one masters all of it. The builder's edge, now, is seeing all of it clearly enough to direct AI across it and catch it where it is wrong. Next in the series: why that reach makes the generalist valuable again.

And to say it plainly: this map is the core, not the whole. Every industry adds layers — a regulatory regime, a channel, a consumable, a tool — that no single list will hold. That is not a gap in the argument; it is the argument. The stack is deeper than any one person can carry in their head, which is exactly why the builder's job now is to see it, and let AI go deep inside each layer.

Sources

Software build and operate: SaaS architecture, DevSecOps, billing and support (industry guides, 2026). Tax: US sales-tax nexus, EU VAT OSS, GST and digital-services tax; tax-engine platforms (Avalara, TaxJar, Anrok, Paddle). Finance: ASC 606 / IFRS 15 revenue recognition. Compliance: PCI DSS, GDPR/CCPA, SOC 2, WCAG/Section 508, EAR. Hardware lifecycle: EVT/DVT/PVT, PPAP/FAI/IQC supplier qualification, dimensional-weight and dangerous-goods shipping, cold chain / GDP, global certification (CE, FCC, UL, CCC, PSE, KC, BIS). Consumable compliance: NSF/FDA food-contact, REACH/RoHS, ISO 13485/IEC 62304, EU IVDR/CLIA, UN 38.3. All web-verified 2026-08.

FAQ

Is a software product really as complex as a hardware one?
They are different, not lesser. A pure software product carries a deep build stack (architecture, data, DevOps, security) plus an operate stack that is largely government-enforced: tax across jurisdictions, PCI-compliant payments, revenue recognition, privacy (GDPR/CCPA), accessibility, and export rules. A connected product adds a physical stack on top of all of that, so it is a superset — but software is not the simple side.

What are all the layers that go into building and running a product?
Roughly: the software build (product, frontend, backend, data, DevOps, security, AI, QA, distribution); for a device, the physical build (mechanical, electronics, power, firmware, connectivity, sourcing, manufacturing, certification); any consumable and its supply chain; and the operate stack (marketing, sales, billing, tax, finance, support, legal/privacy, returns) — plus, for hardware, shipping and per-country certification.

Why do people underestimate what goes into a software product?
Because "full-stack" describes only the build of one product, and the business and compliance half — tax, payments, revenue recognition, privacy, accessibility — is invisible until you have to ship in a real market. That half is a wall of government-enforced complexity that a code-only view never sees.

What does a connected hardware product add over software?
Everything software needs (it still has a cloud, app, and backend) plus industrial and mechanical design, electronics and power, firmware, connectivity, prototyping (EVT/DVT/PVT), supplier qualification, manufacturing and yield, design-for-shipping (dimensional weight, hazmat, cold chain), country-by-country certification, field service, and often a recurring consumable with its own chain and compliance.

How can one person span a stack this big?
Not by mastering it — by being aware of it. Knowing each layer exists lets you give AI strong context, verify what it produces, and know when to bring in a specialist. AI supplies the depth in any one layer; the builder supplies the map across all of them.

This is Part 1 of the AI Builder series. The short version lives on my LinkedIn; the whole series — one layer at a time, each with its own keywords and prompt — lives on my profile.