I didn't know Python. I knew exactly what the product needed to do.
I found a small startup paying for leads built from public information, with regulatory research still bottlenecked through its CEO. I defined an internal sales and compliance research product, then used AI-assisted development to bridge my coding gap and build a working tool.
Build mode
Product judgment + AI-assisted implementation
- Role
- Product and operations lead on a six-month engagement
- Focus
- Lead sourcing, regulatory research, workflow design, internal tooling
- Delivery
- AI-assisted development with Python and Tkinter
- Users
- CEO, roughly three managers, and nine sales representatives by engagement end
In 30 seconds
- The problem
- Nuvii could not scale because the CEO was the workflow — paid lead sourcing, regulatory research, SOP preparation, and partner middleman all ran through one person. The leads it paid for were assembled from public government records.
- My vantage point
- I joined on a six-month contract to find process gaps and reduce manual labor, so I started with discovery instead of assuming purchased leads were unavoidable.
- What I owned
- Requirements, workflow and product design, the government-source pipeline, the extraction, enrichment and normalization approach, the database, the internal search experience, and the AI-assisted implementation, debugging, and testing.
- Outcome
- 9,000+ New Jersey regulatory and licensing PDFs in the prototype source set, a roughly 10-day refresh, research that took days producing usable material in minutes, and paid lead purchasing paused for roughly the final four months of the engagement.
The operating constraint
The CEO was the workflow.
Nuvii had only a few people, with most of its budget directed toward experienced cold-call sales agents. I joined for six months to find bottlenecks, create processes, and reduce manual work.
Find or purchase leads
Research prospects
Support relationship closing
Research state requirements
Prepare compliance resources
Manage partners and transactions
Nuvii didn't just need more salespeople. It needed to stop making the CEO the operating system.
The economic question
01
Why are we paying for leads?
I started with discovery rather than assuming purchased leads were unavoidable. How did lead providers find prospects? What made a lead valuable? Who did the sales team most want to reach?
Newly licensed businesses and companies entering the hemp and cannabis market were especially useful. State by state, I found public government licensing records with business names, license categories, approval or pending status, issue information, and other source-provided details.
The opportunity was straightforward: collect the public data, structure and enrich it where appropriate, and turn it into a proprietary prospect database instead of repeatedly buying the source material back from someone else.
state + license status + business category
Newly approved prospects
Structured from public, source-provided licensing information
Pending approvals
Structured from public, source-provided licensing information
Category-specific businesses
Structured from public, source-provided licensing information
Conceptual sales view — not an original application screenshot
Before
Buy the leads.
- Budget directed at third-party lead lists assembled from public government information.
- Prospect research and regulatory research ran through the CEO.
- Preparing compliance and SOP material could take days per transaction.
- The CEO sat in the middle of partners and transactions, so the work could not run in parallel.
After
Own the source.
- Public state licensing records collected, structured, and refreshed roughly every 10 days.
- A normalized internal database the sales team could query directly.
- Regulatory and SOP material assembled from government sources into a self-serve internal resource.
- Paid lead purchasing paused for roughly the final four months of the engagement.
Conceptual before/after — no spend figures or closed-deal outcomes are claimed
9,000+
New Jersey regulatory and licensing PDFs in the prototype source set — not 9,000 unique companies.
One business could have multiple files for different categories or statuses. The source set included approvals and pending approvals, with remembered categories such as cultivator, manufacturer, wholesaler, and distributor.
Those were relevant New Jersey examples, not a claim that every state used the same categories or structure.
The data product
03
Turn public documents into records the sales team could use.
- stage_01
Public records
State licensing sources
- stage_02
Discover & download
PDFs and published records
- stage_03
Extract
Business and license fields
- stage_04
Enrich
Public company websites, when useful
- stage_05
Normalize
State-specific data into common fields
- stage_06
Database
Shared structured records
- stage_07
Sales views
Queries the team could use
Conceptual processing pipeline — not an original application screenshot
The 9,000+ figure counts New Jersey regulatory and licensing PDFs in the source set, not companies or leads. One business can appear across several documents for different categories, statuses, or license history.
Public source document
STATE LICENSING RECORD
Business and license details published in the source's own format.
Normalized internal record
- business_name
- Source-provided business
- license_type
- Cultivator / manufacturer / other
- status
- Approved / pending / source status
- issue_date
- When available
- expiration_date
- When available
- contact
- Source or public website
- state
- Publishing jurisdiction
The system refreshed approximately every 10 days, updated the shared database, and ran queries or transformations that made raw records useful to sales.
When licensing documents lacked useful sales context, the workflow could visit a company's public website for additional contact or business and product information where available.
Every state published licensing information differently. Different formats, categories, and structures meant the collection logic could not simply be copied from one state to the next.
AI-assisted build
05
One small problem: I didn't know Python.
I understood the users, bottleneck, required data, desired workflow, and what useful output should look like. I turned that into a large requirements and user-story set, then used ChatGPT primarily — with Grok and Claude as well — as development leverage.
Prior Python expertise: not the point.
The result wasn't proof that I had suddenly become a software engineer. It was proof that the distance between a product idea and a working internal tool had gotten much shorter.
Define
Problem, journey, requirements, and useful output
Implement
AI-assisted code, primarily with ChatGPT
Run
Test locally and inspect actual behavior
Debug
Errors and wrong behavior become the next input
Validate
User feedback and journey mapping
Refine
Update requirements and repeat
For nearly two months, the work cycled through implementation, local testing, errors or wrong behavior, AI-assisted debugging, user feedback, journey mapping, and revised requirements. I made the product decisions: what to capture, how the workflow should behave, what was wrong, and when it was usable.
Delivery & adoption
06
A local prototype became shared operating leverage.
What actually shipped
A Python and Tkinter application installed locally on company-provided computers.
A shared central database behind the workflow.
No login or authentication layer existed in the prototype.
The proof of concept began with the CEO and was intended to expand to sales. By the end of my engagement, I remember use across the CEO, roughly three managers, and nine sales representatives.
The sales team grew from two representatives when I joined to nine by engagement end. I do not claim Compliance Navigator caused that growth. It removed part of the operational constraint that made expansion harder and gave the broader team access to workflows that had depended heavily on the CEO.
The system expanded beyond New Jersey across the eligible states the business targeted. I am not claiming a precise nationwide coverage count, because each state published its records differently and coverage grew state by state.
Paid leads paused.
For roughly the final four months of the six-month engagement, Nuvii stopped purchasing third-party leads because the internal prospect pipeline was sufficient for the small sales organization.
No closed-deal or revenue attribution is claimed.
- Days → minutes
- Manual research and preparation could become a workflow producing usable material in minutes. No precise benchmark was tracked.
- 2 → 9
- Sales representatives during the engagement. This is team growth observed over the same period, not an outcome attributed to Compliance Navigator.
- 9,000+
- New Jersey regulatory and licensing PDFs in the prototype source setDocuments, not companies — one business can appear in several files
- ~10 days
- Approximate refresh cadence for collecting and restructuring source data
- ~4 months
- Final portion of the six-month engagement when Nuvii stopped buying third-party leads
What I'd do next
08
Treat the prototype like a real internal data product.
These are future improvements, not features represented as shipped.
Access
future_01Authentication and role-based access for a real internal product
Deployment
future_02Centralized web delivery instead of local installation
Reliability
future_03Better observability, source health, and data-quality monitoring
Sources
future_04More robust adapters for the different way each state publishes records
Compliance
future_05Explicit human verification and versioning as source requirements change
AI workflow
future_06More deliberate use of modern coding tools while keeping product judgment human
Reflection
09
My value here wasn't knowing Tkinter syntax. It was recognizing that a small company was paying for information it could source itself, understanding the operating bottleneck, defining a useful product, and finding a way to get it built without a traditional engineering team.