Outcome operating system
Vyntara
An outcome operating system: brands fund measurable results, contributors deliver them, and payment follows verification.
Deployed and usable through a labelled demo workspace. Settlement is simulated or devnet-only; the on-chain escrow program is not built.
- Period
- Oct 2026
- Status
- Prototype
- Role
- Product design, Full-stack engineering
- Built with
- Astro 7, React 19
Screenshot of the running product.
The problem
Why this needed to exist
Companies mostly pay for activity — hours, posts, deliverables — when what they actually want is an outcome: signups, qualified leads, verified reach. The gap between the two is where budgets leak.
Contributors, whether creators, freelancers or AI agents, carry the opposite risk: they deliver, then wait on a decision nobody has written down. There is rarely a shared record of what was promised, what counts as evidence, and what was verified.
Who it’s for
- Founders and operators funding growth work
- Finance teams who need to see where capital sits
- Creators and contributors paid against results
- Reviewers verifying submitted evidence
The solution
How it works
Vyntara treats a unit of work as an outcome with a budget attached. A brand declares the target, the evidence rules and a payout model; contributors take it up and submit evidence; a reviewer verifies it; and rewards are released against verified value only.
The product is split into two workspaces that share one database — a brand command centre and a contributor workspace — plus a read-only platform console for operators and a public campaign space anyone can browse without a wallet.
An outcome, end to end
- 01DefineTarget, evidence rules, reward model
- 02FundBudget committed to the campaign
- 03ExecuteContributors take it up
- 04VerifyReviewer decides on evidence
- 05RewardRelease against verified value
- 06ReputationComputed from verified work
Implemented
What’s actually built
Sign In With Solana
Real ed25519 verification of a wallet-signed message. Single-use nonces are consumed atomically, so a replay race fails closed. Signing in is a message, never a transaction.
Two workspaces, one role decision
An account is a brand or a contributor, set once on first sign-in and read back from the database on every request. Each side gets its own shell and pages; each is redirected away from the other.
Campaign lifecycle
A state machine refuses illegal transitions. Fixed, tiered and performance reward models cap payout and explain themselves before anyone commits.
Evidence and verification
Contributors submit evidence against a campaign’s rules; reviewers decide. Verification is currently human review — the schema anticipates automated providers, none are built.
Idempotent settlement
Settlement is keyed by a unique database index, so a duplicate is rejected by the database rather than a check that could race. A settlement is confirmed because the cluster said so, never because a wallet returned a signature.
An AI console that cannot invent numbers
Questions are parsed to an intent and answered by a typed SQL query scoped to the caller’s organisation. Every answer carries the records behind it and is labelled as simulated — no model is asked to recall a figure.
Tenant isolation
Every repository call takes the organisation id from the verified session. A cross-tenant read returns nothing, indistinguishable from a record that does not exist.
Honest demo mode
Anyone without a wallet can enter a seeded workspace through a clearly labelled demo entry. Every illustrative figure carries a DEMO marker.
Interface
Screens from the real product
The public landing page — the product in one screen. Campaigns move through a state machine that refuses illegal transitions. One campaign: target, budget, evidence rules and payout ladder. Reward models explain themselves in plain language before anyone commits. Treasury: available, committed, in escrow, distributed. The AI console answers from typed queries over the workspace, and shows its sources. Reputation is computed from verified work, not self-reported. The operator console refuses anyone who is not an operator. The investor briefing, including a disclosures section on what is real.
My role
What I did
Product definition, information architecture and visual direction ("Obsidian Command Center + Liquid Glass + Financial Terminal"), the token-driven design system, and the full implementation across 42 routes: public site, investor briefing, both workspaces and the operator console.
Also the verification harnesses — a render suite that boots every page against a seeded database, a crawl that resolves every internal link, and a responsive audit — and a walkthrough video assembled from real captures with Remotion.
Responsibilities
- Product design
- Full-stack engineering
- Design system
- Investor narrative
Stack (verified from source)
- Astro 7
- React 19
- TypeScript
- PostgreSQL
- Drizzle ORM
- PGlite
- Solana (@solana/kit)
- Vitest
- Remotion
Decisions
Technical and design choices
- 01
Astro over Next.js
The public and investor surface needed to be cinematic but cheap to load. Astro renders most pages to HTML with no hydration; React islands hydrate only where the product is genuinely interactive — sign-in, the campaign wizard, the AI console.
- 02
Real Postgres with zero setup
PGlite (Postgres compiled to WASM) is the default driver, so a fresh clone runs with no credentials, and the same Drizzle schema runs against managed Postgres in production.
- 03
Sessions, not JWTs
An opaque random token with only its SHA-256 hash stored. Sessions are revocable, so "sign out everywhere" actually works.
- 04
Status never by colour alone
Every status badge carries a shape marker as well as a colour, and every animation has a reduced-motion fallback.
Trade-offs
Challenges along the way
- 01
Keeping the pitch and the product apart
An investor page naturally describes the destination. The build keeps an explicit disclosures section stating what is real, simulated, in progress and planned, so the roadmap is never read as shipped.
- 02
A wallet that would not show the sign-in request
Wallets refuse to render a SIWS request missing URI and Version fields. The message is now built from the configured origin — never the request’s Host header — with an expiration time.
- 03
Settlement without an escrow program
Rather than fake on-chain custody, settlement is a non-custodial, client-signed transfer with a memo, verified against the cluster, and mainnet is refused outright until there is a program to settle against.
Results
What can be checked
Test suite
More than 150 Vitest tests, including a render suite that boots every real page against the seeded database and a crawl that resolves every internal link.
- vyntara-frevana.vercel.app (opens in a new tab)
Deployed
Public site, investor briefing and demo workspace running on Vercel.
Lessons
What I took away
- Writing down what is simulated is a feature, not a disclaimer. It forced cleaner boundaries in the code: the demo rail, the devnet rail and the (refused) mainnet rail are separate implementations behind one interface.
- An AI surface that only composes answers from typed queries is less impressive in a demo and far more trustworthy in a finance product.
What’s next
Planned — not built
Planned work
- An audited Anchor escrow program on Solana, with on-chain release authority
- SPL token (USDC) settlement — today the rail can only move SOL
- Automated verification providers alongside human review
- Evidence file uploads, notifications and webhooks
Current limits, stated plainly
- No on-chain escrow program exists yet; the investor roadmap describes it, the code does not contain it.
- The AI console does not call a model; answers are computed and labelled simulated.
- Mainnet settlement is refused by design.