Virginia’s cannabis market opens in 2027. I’ve spent two years building a payment layer for a problem most people still cannot see.
I do not have a victory-lap story for you.
I do not have a seven-figure revenue screenshot.
I do not have thousands of merchants, a giant funding announcement, or a polished photograph of a team pretending everything happened exactly according to plan.
I do not have regulatory approval.
I do not have a live payment network.
What I have is a working nonproduction sandbox, hundreds of documented development hours, many more hours I stopped counting, several rebuilt versions, a growing stack of evidence, and a body that no longer remembers what a healthy relationship with sleep feels like.
For nearly two years, I have been building what I believe could become part of the future payment infrastructure for Virginia’s regulated cannabis market.
I call it Green Light Pay Initiative
Before I explain it, one correction matters.
Virginia is not passing a law that makes cannabis federally illegal. Cannabis already exists inside a complicated conflict between state authorization and federal law.
Virginia’s 2026 legislation establishes a regulated retail marijuana market, with the Virginia Cannabis Control Authority currently targeting July 1, 2027 for retail sales. Draft regulations are scheduled for release in September 2026, with the framework continuing to develop from there.
But a Virginia license does not automatically erase the separate federal treatment of cannabis or the financial-compliance obligations surrounding marijuana-related businesses.
That contradiction is the problem.
A state can license cultivation, testing, transportation, delivery, and retail. It can require seed-to-sale tracking, collect taxes, establish product rules, and punish unlicensed operators.
But none of that magically turns cannabis into an ordinary retail category for the national financial system.
That gap—between a lawful state transaction and a federally complicated financial transaction—is where I have spent the last two years of my life.
The two years did not “fly by”
People say that after long projects.
“Before I knew it, two years had passed.”
That is not what this felt like.
These two years crawled.
They moved one ledger imbalance at a time.
One broken authorization flow at a time.
One security question at a time.
One night of believing I had finally solved something, followed by one morning of realizing I had only moved the problem somewhere less visible.
I know the internet loves stories about somebody building an application over a weekend.
This was not that.
I built around full-time responsibilities and then gave the project full-time hours of its own. I worked during the day, worked through the night, slept in pieces, woke up thinking about state transitions, and returned to the same problems before my mind had properly recovered from the last attempt.
There were nights when I did not sleep at all.
More often, I slept just enough to technically say that I had slept, then got back up and tried to reason clearly about payment integrity, reconciliation, authorization boundaries, custody, audit evidence, security controls, and an industry caught between two legal realities.
I will not claim I literally went without sleep for months. That would be dishonest, and it would turn the truth into marketing.
The truth was more ordinary and more damaging.
I repeatedly treated sleep as negotiable.
I gave the project the hours that should have restored me. I gave it mornings, weekends, disposable income, attention, patience, and the part of my mind that used to know how to stop working.
That is not a productivity method.
It is not advice.
It is not something I am proud enough to recommend.
Sleep deprivation did not make me more brilliant. It made simple tasks take longer. It made small setbacks feel enormous. It made me reread the same logic until the words stopped looking like a language.
It made time move even more slowly.
A twenty-minute problem became a two-hour problem. A two-hour correction became a two-day rebuild. A rebuilt component exposed another assumption underneath it, and suddenly I was back at the beginning, except more tired and slightly less naïve.
There were long stretches when this project was not exciting.
It was tedious.
There was no music playing behind the work. No montage. No audience waiting to applaud when the screen finally changed.
There was just the next thing that had to be made true.
That is what nearly two years of development actually felt like.
Not constant inspiration.
Obligation.
The problem would not leave me alone
The simple version sounds easy:
“Build a better way for people to pay at licensed cannabis retailers.”
But accepting a payment is not the hard part.
The hard part is determining what every participant is legally and operationally responsible for, proving that each required event occurred, preventing one system from quietly trusting another, and preserving enough evidence to reconstruct the transaction afterward.
A customer wants a payment to feel ordinary.
A merchant needs the sale tied to the correct amount, inventory record, taxes, and point-of-sale event.
A financial or settlement partner needs to know exactly what it is touching and whether the parties are qualified.
A regulator needs traceability.
An auditor needs evidence.
A security reviewer needs to know that the customer cannot alter the amount, destination, asset, or transaction state.
The operator needs the system to work without reading a technical manual at the counter.
Those interests do not automatically fit together.
Most payment products promise to remove friction.
In regulated cannabis, some friction represents a legal boundary, a required check, or a piece of evidence. You cannot simply remove it. You have to place it correctly, make it understandable, and prove that it happened.
That distinction became the center of Green Light Pay.
I am not trying to build a trick that disguises a cannabis transaction.
I am not trying to hide the merchant category.
I am not trying to pass money through a maze until nobody can identify where it came from.
I am not trying to declare that technology has somehow overruled federal law.
Green Light Pay is being designed around the opposite principle:
Do not hide the facts. Make the facts exact, independently verifiable, reconcilable, and difficult to alter.
What Green Light Pay is—and what it is not
Green Light Pay is currently an early-stage, nonproduction payment-orchestration, verification, reconciliation, evidence, and merchant-control layer.
It is not currently a bank.
It is not a licensed financial institution.
It is not a money transmitter.
It does not hold customer funds.
It does not provide custody.
It does not claim to make a federally prohibited transaction lawful.
It does not process live cannabis payments today.
The architectural hypothesis is based on separating responsibilities instead of allowing one application to pretend it can legally and competently perform every role.
Under that model:
The merchant and point-of-sale system remain responsible for product eligibility, customer requirements, taxes, inventory, and state reporting.
Qualified and appropriately licensed partners would handle the regulated responsibilities assigned to them, potentially including screening, custody, conversion, and settlement.
Green Light Pay would coordinate the payment intent, independently verify required transaction facts, maintain an operational ledger, reconcile the different records, enforce merchant controls, and produce audit evidence.
That separation matters.
If the payment layer starts performing functions that belong to a bank, custodian, exchange, money transmitter, merchant, or state reporting system, it may create more risk than it removes.
I have spent an unreasonable amount of time learning that a useful financial product is not defined only by what it can do.
It is also defined by what it refuses to do.
What exists in the sandbox today
The current sandbox demonstrates a fictional $42.50 transaction through a five-stage flow:
Counter
The merchant initiates an exact payment intent using final USD cents and a unique transaction reference.
Green Gate
The system checks whether the necessary partner and transaction conditions are satisfied before allowing the flow to continue.
Customer Handoff
A genuine, short-lived QR handoff presents the customer with the exact approved transaction facts. The sandbox uses fictional wallet activity; it does not move live customer money.
Watchers
Two independent server-side observers evaluate the transaction facts instead of allowing the interface to declare its own success.
Receipt
A final receipt is not created merely because somebody clicked “submit.” It is released only after the transaction reaches the required reconciled state.
The sandbox is designed to verify exact facts such as the expected program, asset, source, destination, amount, signature, and finality status.
It maintains a balanced double-entry operational ledger.
It performs a four-way reconciliation between the point-of-sale record, transaction evidence, partner settlement record, and internal ledger.
It maintains a tamper-evident, hash-linked audit trail.
It can produce a downloadable evidence bundle so the completed result is not reduced to “trust the dashboard.”
One defined version passed all ten tests in its internal test suite.
That is meaningful progress.
It is not an independent security audit.
It is not legal approval.
It is not production certification.
It is not proof that a bank, regulator, merchant, processor, or licensed cannabis operator has approved the architecture.
I refuse to turn a successful sandbox test into a claim it cannot support.
The unfinished work is part of the story
Founder posts usually move quickly past the unfinished parts.
I cannot do that here, because the unfinished parts are where the real risk lives.
The next hardening work includes stronger evidence endpoints, token rotation, fragment-only capability handling, stricter sandbox isolation, additional security headers, tighter record-access controls, and eliminating any path that could bypass the intended submission sequence.
The longer-term architecture still needs:
Encryption at rest
Role-specific permissions and capability keys
Separate interfaces for customers, merchants, owners, operations reviewers, and compliance reviewers
Formal threat modeling
External security review
Regulatory and legal review
Partner qualification standards
Merchant and point-of-sale integration contracts
Documented failure and reversal handling
Production-grade identity and access controls
A clear process for adapting the product to Virginia’s final regulations
There are still questions I cannot answer alone.
There are assumptions that may not survive expert review.
There are parts of the architecture that may need to be removed completely.
That possibility does not invalidate the work.
It is the reason to build and review the system before Virginia’s retail market opens—not after real merchants and real customers are already depending on it.
What this project has taken from me
I have struggled with how to write this section without sounding dramatic.
The honest answer is that the project has taken more than I intended to give it.
At first, I thought I was giving it time.
Then I realized I had given it my schedule.
After that, I gave it my ability to mentally leave work.
Eventually, almost every ordinary moment became a place where the project followed me.
I would try to rest and think about reconciliation.
I would try to sleep and see a missing security boundary.
I would finish one version and immediately start listing why it was not strong enough.
I stopped experiencing progress as a celebration. Progress became permission to move to the next problem.
There were no shortcuts that made the hard sections disappear.
AI helped me move faster, examine more possibilities, draft requirements, test assumptions, and turn ideas into working components. It did not remove the responsibility to understand what the system was claiming.
In some ways, AI made the standard higher.
If software could be produced faster, then I had less excuse for leaving its logic unexplained. If a prototype could be generated quickly, then the evidence distinguishing a functional system from a convincing demonstration became even more important.
I did not want to build an attractive screen that said “verified.”
I wanted to be able to answer:
Verified by whom?
Against what independent evidence?
Using which exact transaction facts?
At what point in the transaction lifecycle?
What happens when the observers disagree?
What prevents the interface from bypassing the verification?
What record allows a third party to reconstruct the decision afterward?
Each answer created more work.
Each answer also made the project more real.
I have paid for infrastructure, tools, domains, development, and the cost of repeatedly changing direction when the evidence showed that the earlier version was not enough.
I did not have a giant company absorbing those costs.
I absorbed them.
More importantly, I absorbed the time.
Money can sometimes be earned again.
There is no mechanism for refunding two years of nights.
I cannot go back and recover the mornings when I was too exhausted to feel like myself. I cannot retroactively make the process healthier. I cannot pretend the work did not affect me simply because sacrifice makes a better founder story.
Some of it was unnecessary.
Some of it came from inexperience.
Some of it came from believing that urgency could compensate for not yet having the right people around the project.
Some of it came from caring so intensely that stopping felt like abandoning the future I could already see.
I have made mistakes.
I have overextended myself.
I have tried to solve too many layers simultaneously.
I have sometimes mistaken movement for progress.
I have learned that determination without structure can consume a person long before it produces a company.
But I also know what remains after the excitement is gone.
The work remains.
And I kept doing it.
Why I am still here
Virginia’s market is no longer a distant hypothetical.
The Commonwealth’s current timeline calls for draft regulations in September 2026, final regulations by the end of the year, initial licensing activity in early 2027, and retail sales beginning July 1, 2027.
The clock is real now.
Cannabis operators will need systems that do more than make payment convenient.
They will need systems capable of producing evidence.
Financial partners will need visibility.
Merchants will need operational controls.
Customers will need something understandable and dignified.
Regulators will need traceability.
Everyone will need to know which participant is responsible when a transaction fails, a record disagrees, or a required check never occurs.
I believe a payment layer can become more than a button at checkout.
It can become a compliance surface.
It can create a shared, reconcilable record between parties that do not—and should not—blindly trust one another.
It can reduce ambiguity without pretending to remove the law.
That is the future I have been trying to build toward.
Not a way around accountability.
A way to make accountability operational.
What “building in public” means to me now
Building in public cannot mean posting only when something works.
It cannot mean replacing documentation with confidence.
It cannot mean describing every planned feature as though it already exists.
If I am going to build this publicly, then the public record needs to contain:
What has been verified
What remains experimental
What has failed
What changed and why
Which claims the evidence supports
Which claims I am deliberately refusing to make
What the product currently cannot do
What expert review is still required
That is the standard I want Green Light Pay held to.
I would rather have somebody find a fatal assumption now than have a merchant discover it after retail sales begin.
I would rather rewrite the architecture than defend something unsafe because I am emotionally attached to the hours already invested in it.
Those hours are gone either way.
Sunk time is not regulatory approval.
Exhaustion is not product-market fit.
Conviction is not security.
A working sandbox is not a production financial network.
I know the difference.
What I am asking from Reddit
I am not asking anyone to invest.
I am not asking anyone to trust me because I lost sleep.
I am not asking for sympathy, blind encouragement, or another person telling me to “keep grinding.”
I am asking for informed criticism.
If you work in payments, compliance, banking, cannabis operations, point-of-sale infrastructure, information security, accounting, regulation, or financial law, I want to know where this architecture breaks.
Specifically:
Is the proposed separation between merchant responsibilities, partner responsibilities, and orchestration responsibilities realistic?
What function have I placed inside Green Light Pay that belongs somewhere else?
What evidence would a merchant, financial institution, regulator, or auditor actually require from each transaction?
Is four-way reconciliation useful in this context, or am I creating complexity without enough operational value?
What failure state am I still treating like an edge case when it should be central to the design?
What language makes the project sound as though it is making a legal or regulatory claim it cannot support?
What would you need to see before you would even consider participating in a controlled pilot?
If you are a Virginia operator, what payment or reconciliation problem are technical founders consistently misunderstanding?
I do not need people to tell me the idea is brilliant.
I need people capable of telling me precisely why it is wrong.
If the project cannot survive scrutiny, it should not touch regulated commerce.
Where I stand after two years
I am tired.
That is true.
I am also clearer than I was when I started.
Two years ago, I thought I was building a payment experience.
Now I understand that I am testing a much larger hypothesis about verification, role separation, reconciliation, and evidence inside one of the most legally complicated retail environments in America.
I do not know whether Green Light Pay will become the infrastructure I imagine.
Nobody honest could guarantee that.
I know only that it has moved beyond an idea.
It now has an architecture that can be challenged, a sandbox that can be tested, transaction states that can be inspected, limitations that can be named, and a public standard against which future claims can be measured.
That is not the finish line.
It may finally be the real beginning.
I have given this project more of myself than I knew I was capable of giving. Some of that sacrifice made the work possible. Some of it was unhealthy. Both statements can be true.
I cannot recover the time.
What I can do is make sure the next stage is worthy of it.
Virginia’s regulatory framework is taking shape now.
The market is approaching.
The difficult federal–state conflict remains.
And I am still here.
Not celebrating.
Not pretending the system is finished.
Not asking you to believe a founder story.
Still building.
Still documenting.
Still correcting.
Still trying to turn two years of private exhaustion into something the public can examine.
Do not tell me to keep grinding.
Tell me what breaks.
