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
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
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
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
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.
The system refreshed approximately every 10 days, updated the shared database, and ran queries or transformations that made raw records useful to sales.
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.
A wider product
04
From lead generation to Compliance Navigator.
Finding prospects was only one bottleneck. After a relationship was established, the CEO could spend days researching and preparing the regulatory and SOP information needed to support a transaction.
Envisioned retrieval
Government-source compliance information organized into a digestible internal PDF-form resource
The underlying requirements came directly from government websites. AI-assisted processing helped organize and summarize source material; it was not intended to invent, rewrite, or modify regulatory requirements. The tool did not provide legal advice, and the precise final PDF structure is not represented here.
The CEO reviewed and approved the proof of concept before it entered the workflow. I remember a very positive review of the sample, but I am not inventing a quote.
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, without claiming a precise nationwide coverage count.
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.
- 9,000+
- New Jersey regulatory and licensing PDFs in the prototype source set
- ~10 days
- Approximate refresh cadence for collecting and restructuring source data
- 2 → 9
- Sales representatives during the engagement, without claiming the tool caused growth
- ~4 months
- Final portion of the engagement when Nuvii stopped buying third-party leads
- Days → minutes
- Manual research and preparation could become a workflow producing usable material in minutes. No precise benchmark was tracked.
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.