Regulated Industries
Compliance Is Your Moat: Building the SB3 Fortress

Compliance Is Your Moat: Building the SB3 Fortress
Why I Call It "The Fortress"
TL;DR
In regulated markets like hemp and cannabis, compliance infrastructure becomes a durable competitive moat.
I built what I call the SB3 Fortress: a compliance architecture that enforces real-time age verification, COA validation, THC limit enforcement, and immutable audit trails.
The result: 250+ vendors, zero compliance violations since launch, and a 5–7 month head start over any competitor attempting to enter the market.
Treating compliance as core product infrastructure, not an afterthought, created our most defensible advantage.
250+ vendors operating with full regulatory confidence
Ten months of solo development.
Zero compliance violations since launch.
250+ vendors operating with full regulatory confidence.
Sub-500ms response times, even while validating age verification, COA expiration, and THC limits on every transaction.
Most technical founders treat compliance as a cost center, something to outsource or paper over with manual checks. I treated it as core product infrastructure.
That decision created a moat competitors still haven’t crossed 18 months later.
Here’s how, and why you should think about compliance the same way if you’re building in a regulated industry.
The Regulatory Landscape: Texas Hemp After SB3
The Regulatory Landscape: Texas Hemp After SB3
This isn’t theoretical. These were hard requirements I had to encode directly into HempDash’s business logic.
HB 1325 (2019) legalized hemp in Texas, defining it as cannabis containing ≤0.3% Delta-9 THC by dry weight. It enabled CBD and hemp-derived products, but left a regulatory vacuum: no age limits, inconsistent testing, and minimal enforcement.
SB 3 (2023) ended that ambiguity.
Effective September 1, 2023, Texas required:
- 21+ age verification for all hemp sales
(For online orders: at delivery, not just checkout) - Certificate of Analysis (COA) for every SKU, validated via third-party labs
- Product labeling showing total THC content and health warnings
- Texas DSHS enforcement authority, including shutdowns for non-compliance
The penalties escalate quickly:
- First offense: Class C misdemeanor (up to $500)
- Subsequent violations: Class B misdemeanor
- Ultimate risk: loss of vendor trust, which is fatal for a marketplace
I launched HempDash in March 2024, six months after SB3 took effect.
Building the Fortress:
Three I made three foundational decisions when designing HempDash’s compliance system. Two were correct from day one. One I’d change in hindsight.
1. Real-Time Age Verification at Delivery (Not Purchase)
The requirement: SB3 mandates 21+ age verification at point of sale. For on-demand delivery, that's at the customer's door—not when they click "Place Order" in the app.
My implementation: I integrated with a third-party ID verification service (similar to Jumio/Onfido) that courier drivers trigger via the Courier Portal app at delivery. The flow:
- Customer places order in Customer App (no age verification yet)
- Order routes to courier through our dispatch system
- Courier arrives at customer location, opens delivery screen in Courier Portal
- App prompts: "Scan customer ID to verify 21+"
- Driver uses phone camera to scan ID (barcode/PDF417 chip on Texas DL)
- Verification service validates ID authenticity + extracts birthdate
- FastAPI backend calculates age from birthdate
- If age ≥ 21, delivery proceeds. If not, order cancelled + refund triggered
The key decision: delivery cannot be completed unless verification succeeds.
No overrides. No “I checked visually.” No compliance debt.
8.2% failure rate breaks down: 4.1% customer not present, 2.8% forgot ID, 1.3% under 21
Why This Was the Correct Call
I could have implemented age verification at checkout. The UX would have been simpler, and fewer deliveries would have failed.
But SB3’s language is explicit: age verification must occur at the point of sale, which legally means the moment money and product change hands. For on-demand delivery, that moment is the customer’s door.
Verifying at checkout would have been easier. It also would have been non-compliant.
More importantly, delivery-time verification gives us cryptographic proof of compliance for every completed order. Each delivery records:
- ID scan timestamp
- Extracted age data
- Verification result
All of it is written to an immutable audit trail (described below).
The tradeoff is real: roughly 8% of deliveries fail age verification, customers aren’t present, forgot their ID, or are under 21.
That’s lost revenue.
It’s also regulatory certainty.
And because the data is irrefutable, we’ve never had to defend ourselves to DSHS.
2. COA Tracking with Auto-Expiration Logic
87% re-activated within 72 hours after vendors uploaded new COAs
The requirement
Every hemp product sold in Texas must be backed by a valid Certificate of Analysis (COA) showing cannabinoid test results.
While SB3 doesn’t specify an expiration period, industry standard is 12 months, after which a COA is considered stale.
The implementation
When vendors onboard products through the Vendor Portal, they must provide:
- Product details (name, description, price, images)
- A COA document (typically a PDF from third-party labs such as SC Labs or ACS Laboratory)
- COA metadata: issue date, expiration date, lab name, and tested Delta-9 THC percentage
I modeled this explicitly in PostgreSQL using a product Coas table with a one-to-many relationship to products, since new batches require new COAs.
A daily Celery job runs at 2:00 AM Central to enforce compliance:
- Flags expired COAs
- Automatically disables affected SKUs
- Prevents non-compliant products from being listed or sold
No manual intervention. No reminders. No compliance drift.
When a COA expires, the product automatically becomes unavailable in the Customer App. Vendors get an email notification: "Your COA for [Product Name] expired. Upload a new COA to restore availability." No human intervention required.
Why this was correct: COA expiration isn't optional, it's a compliance landmine. If we sold a product with an expired COA and DSHS audited us, that's an immediate violation. Automating this removed human error from the equation. Over 18 months, we've auto-disabled 340+ products due to expired COAs. 87% of those vendors uploaded new COAs within 72 hours, because we made the workflow dead simple.
The data validation layer: I also enforce THC limits in code. When a vendor uploads a COA, the backend validates:
- Delta-9 THC % ≤ 0.3% (SB3 limit)
- Total THC (Delta-9 + THCA converted) disclosed on product page
- COA lab is on our approved list (we vet labs for accreditation)
If any validation fails, the product is rejected at onboarding. This happened 23 times in our first 6 months—vendors trying to list products with 0.4% or 0.5% Delta-9 THC, thinking "close enough." Not in the Fortress.
3. Immutable Audit Trail Architecture
The requirement: SB3 doesn't explicitly mandate audit trails, but Texas DSHS has enforcement authority. If they come knocking, I need to prove compliance for every transaction, ever.
My implementation (and my one regret):I built an append-only compliance_events table in PostgreSQL to capture every compliance-relevant action, forever.
Schema highlights:
- event_id (UUID, primary key)
- event_type (enum: age_verification, coa_validation, thc_check, order_completion)
- timestamp (timestamptz, immutable)
- order_id (foreign key)
- event_data (JSONB — ID scan results, COA references, THC calculations)
- signature (SHA-256 hash of previous event + current event payload)
Each row cryptographically references the previous one, creating a tamper-evident, blockchain-like chain without blockchain overhead.
This lets me reconstruct the compliance state of any order, at any point in time, with cryptographic integrity.
Average query time for full compliance report: 380ms
Every compliance-relevant action appends a row. No updates, no deletes (enforced via PostgreSQL RLS policies). The signature field creates a tamper-evident chain—if anyone modified historical data, the hash chain would break.
Why this was mostly correct: We have cryptographic proof of every compliance check. When vendors ask "How do I know you're actually checking COAs?", I can show them the audit trail for their products. When investors ask "What's your regulatory risk?", I can export 18 months of zero-violation data in 30 seconds.
What I'd do differently: I should have used a dedicated event sourcing database like EventStoreDB or at minimum a separate PostgreSQL instance. Storing compliance events in the same database as transactional data creates a recovery risk—if I ever need to restore from backup or migrate databases, I'm risking audit trail integrity. Six months in, I realized this and started daily exports to AWS S3 (encrypted, versioned, with lifecycle policies retaining data for 7 years). But I should have architected it separately from day one.
The compliance dashboard I built for myself: I created an internal-only view in the Ops Dashboard that shows:
- COAs expiring in next 30 days (currently 47 products)
- Age verification failure rate by courier (avg 8.2%, one outlier at 14%)
- Products flagged for THC limit review (currently 0, but had 3 in December)
- Audit trail completeness check (runs daily, confirms no missing events)
This dashboard is how I sleep at night. If something's wrong, I know within 24 hours.
Why Competitors Can't Copy This (The Moat Thesis)
Building the SB3 Fortress took 10 months of solo development.
I shipped compliance infrastructure before the marketplace UI.
Most competitors do it backwards: they launch the sexy front-end, gain traction, and scramble to bolt on compliance when regulators start asking questions.
The moat isn’t just the code, it’s 10 months of deliberate engineering, testing, and operationalizing compliance before going live.
Competitors can copy features; they can’t copy history, proof, and trust.
Even with my exact architecture, they still face integration testing and edge case discovery
Time-to-Replicate is the Moat
Even if a competitor had my exact architecture (which they don’t, because it’s proprietary), it would take 5–7 months of engineering effort at minimum to reproduce the SB3 Fortress:
- 6–8 weeks: integrate ID verification SDKs, test edge cases (expired IDs, out-of-state licenses, vertical vs. horizontal formats)
- 4–6 weeks: build COA upload workflows, validation logic, and auto-expiration systems
- 8–10 weeks: architect and test an immutable audit trail with proper retention policies
- 4–6 weeks: encode Texas-specific business rules (THC limits, labeling requirements, DSHS reporting)
And that assumes no mistakes. Compliance is fractal: every edge case you handle reveals two more.
Vendor trust compounds the moat. 250+ vendors operate on HempDash because we’ve never had a compliance incident. When new marketplaces launch, vendors ask:
“How do you handle age verification? What happens if my COA expires? Have you been audited by DSHS?”
Vague answers = no onboarding. Vendors can’t risk their business.
Results & Validation: Zero Violations, Real Trust
- Zero compliance violations since March 2024 launch
- 250+ vendors with full regulatory confidence; 94% retention after 12 months
- 23,400+ age verifications at delivery; 91.8% success rate
- 4.1% customer not present
- 2.8% customer forgot ID
- 1.3% underage (304 blocked)
- 340+ products auto-disabled for expired COAs; 87% reactivated within 72 hours
- 1.2M compliance events logged in an immutable audit trail; full product/vendor reports in 380ms
- Vendor feedback: 78% cited compliance infrastructure as a top-3 reason they chose HempDash
Compliance isn’t just risk mitigation, it became a sales tool.
- Separate compliance database from day one – mixing events with transactional data is risky; should have used EventStoreDB or a dedicated PostgreSQL instance.
- Build a more guided COA workflow – OCR and auto-validation could reduce vendor errors and onboarding friction.
- Over-communicate compliance to customers – e.g., “Texas law requires age verification at delivery. Have your ID ready!”
- Plan multi-state expansion earlier – hard-coded Texas SB3 rules need to become pluggable compliance engines for other states.
What I got unambiguously right: Treat compliance as first-class infrastructure, not an afterthought. That decision built the moat, earned vendor trust, and made HempDash the regulatory gold standard in Texas hemp delivery.
Retrospective: What I’d Do Differently
- Separate compliance database from day one – mixing events with transactional data is risky; should have used EventStoreDB or a dedicated PostgreSQL instance.
- Build a more guided COA workflow – OCR and auto-validation could reduce vendor errors and onboarding friction.
- Over-communicate compliance to customers – e.g., “Texas law requires age verification at delivery. Have your ID ready!”
- Plan multi-state expansion earlier – hard-coded Texas SB3 rules need to become pluggable compliance engines for other states.
What I got unambiguously right: Treat compliance as first-class infrastructure, not an afterthought. That decision built the moat, earned vendor trust, and made HempDash the regulatory gold standard in Texas hemp delivery.
Takeaways for Founders in Regulated Industries
- Compliance is infrastructure, not a feature – bake it into data models, business logic, and audit systems.
- Automate, don’t rely on humans – encode COA, age, and transaction rules in code.
- Build the audit trail you’d want for regulators tomorrow – immutable, tamper-evident, exportable.
- Your competitors fear regulation – the 6–9 months you spend building compliance is time they won’t.
- Trust is the product – vendors, partners, and customers value compliance more than you think.
The SB3 Fortress took 10 months to build. It’s now the most defensible part of HempDash. If you’re building in a regulated industry and treating compliance like an afterthought, you’re giving away your moat.
About Jonathan Sullivan
Jonathan is the founder and CEO of HempDash, Texas's first compliant on-demand hemp delivery marketplace. Prior to HempDash, he spent 12+ years as a software engineer, including roles at Google working on machine learning infrastructure. He now writes about technical architecture, founder lessons, and building in regulated industries. Connect with him on LinkedIn or Twitter/X.
Excerpt
When I left Google to build HempDash, I treated compliance like core product infrastructure. 10 months of work. Zero violations. 250+ vendors. That's the moat competitors can't cross.