AdminClick to expandpsba.co/admin
Portfolio profile self-service
Secure-link portal that lets each portfolio company update its own profile on the public site. No accounts, no passwords. Admin sees the changes instantly. Part of a three-app suite built for PSBA.
The workflow that wasn’t happening: PSBA wanted to feature its portfolio companies on the public site and publish press releases when companies hit milestones. The manual steps for either were enough that the team knew the work could be automated, but nobody had time to actually set up that automation. So the work just didn’t happen, either manually or automated. Portfolio companies sat unseen on the site. Wins went unannounced.
What I built: a secure-link portal that lets each portfolio company update its own profile on the public site. They edit without an account or password. Admin sees the change instantly. Logos normalize automatically. Part of a three-app suite built for PSBA: portfolio self-service, recording-to-press-release pipeline, financial automations.
What it doesReplaces “we should do this someday” with portfolio companies updating their own profiles in 30 seconds.
What it savesThe decision-to-do-it cost. The site now reflects who’s actually in the portfolio, without anybody scheduling the work.
Who runs itThe portfolio companies maintain their own pages. Admin sees the changes.
The pattern translates to: any organization with a distributed roster that should be maintaining its own entries. Multi-location operators with managers updating store-level information. Family-owned businesses with department heads publishing project updates. Professional services firms with practice leads owning their own bios. Same pattern, bigger inputs.
LiveClick to expandsixfigures.app
A marketing site engineered to be the app’s front end
Custom WebGL build with a liquid gradient backdrop and a custom typography system. Architected to be the front end the accelerator app plugs into. Co-founded with Arsh Haque; the team has helped raise over $200M.
The workflow that wasn’t happening: an AI fundraising platform needs to look like a real product before founders trust it with their pitch, and before partner institutions agree to put their name next to it. The team had the product, the credibility (Techstars alumni, $200M+ collectively raised), and a clear roadmap. What didn’t exist yet was a brand and a marketing site that matched the seriousness of what they’re building. An off-the-shelf template would have read like a side project.
What I built: a custom WebGL marketing site for Six Figures, the AI fundraising platform I co-founded with Arsh Haque. Liquid gradient backdrop, custom typography (Geist Sans plus Instrument Serif italic accents), engineered to be the front end the accelerator and investor tools plug into. When the product wires in, it inherits the same visual system rather than carrying a brochure site bolted to a separate app aesthetic.
What it doesGives the product a premium brand presence that reads as a real company, not a side project. Built to be the product’s design system, not just a marketing landing page.
What it savesThe brochure-versus-product divide most early-stage startups carry. The eventual re-skin pass when the marketing site and the app diverge in look and feel.
Who runs itArsh and me. The site is in production now; the accelerator app plugs in next.
The pattern translates to: any early-stage product where the founders need to look as credible as the product is. Solo founders pitching partner-institution deals. Two-founder companies where one owns design and the other owns engineering. SaaS startups that want a marketing site that won’t get torn down the day the app ships. Same pattern: the marketing site is the product’s design system, not a brochure on top of it.
Dashboard
Click to expand The operating layer for a solo consulting practice
A 15-agent system with a dashboard. Each agent handles a function (research, drafts, meeting prep, opportunity sourcing). Replaces the entire admin layer of a solo consulting practice.
The workflow that wasn’t happening: running a fractional consulting practice systematically without staff. CRM updates, meeting prep, opportunity tracking, draft writing, follow-up reminders. The operating work that traditionally requires a chief of staff or an admin team.
What I built: a 15-agent system with a dashboard. Each agent handles a function (research, drafts, meeting prep, opportunity sourcing, action items, reports). The dashboard surfaces what needs my attention. Everything else runs in the background.
What it doesReplaces the entire admin layer of a solo consulting practice
What it savesThe hiring cost of a chief of staff or admin team. 15 to 20 hours a week of clerical work.
Who runs itKari. Used every day to run kariops.
The pattern translates to: any operator running a business at a scale that would normally need an ops team but doesn’t have one. Fractional executives. GMs at multi-location operators carrying coordination work across sites alone. Family-business operators carrying the chief-of-staff load themselves. Owner-operators at established businesses without internal admin capacity.
Connector
Click to expand An AI visibility tracker that runs inside Claude
A connector that installs inside Claude and tracks how a brand shows up across Claude, ChatGPT, Perplexity, Gemini, and Google AI Overviews, then drafts the page changes to close the gaps. It runs on each user’s own engine keys and never writes to anyone’s site.
The workflow that wasn’t happening: buyers in 2026 ask Claude, ChatGPT, Perplexity, Gemini, and Google AI as often as they Google, and those answers decide whether a business makes the shortlist. Finding out whether your brand even shows up means running queries across five engines and counting mentions, every month. No small business has time for that, much less translating the gaps into page changes.
What I built: kariops-pulse, a connector that installs inside Claude and runs a monthly citation scan across all five engines in parallel. Two-tier mention detection (regex first, model verify second), per-engine and rolled-up citation share, and a diff against last month. It drafts the page changes that would close the gaps and returns them in chat. It is BYOK: each user brings their own engine keys, so kariops never pays for a user’s scans, and those keys are held under three-tier envelope encryption so one leaked secret can’t unlock everyone’s. Read and draft only. It never writes to a user’s site.
What it doesMeasures citation share across five AI search engines monthly, surfaces the deltas, and drafts the page changes to close them, all from inside Claude.
What it savesThe four-hour manual scan across five engines nobody runs. The compounding cost of being invisible in AI search.
Who runs itThe operator, from their own Claude. Their own keys, their own spend, encrypted at rest. No dashboard to log into.
The pattern translates to: any business that needs to be findable in AI search without a marketing team running visibility scans. Professional services firms whose buyers ask LLMs for vendor shortlists. Local businesses whose customers ask AI for recommendations. SaaS products whose buyers compare options through LLMs. The visibility lives in the answers, the answers change monthly, and the scan belongs on a clock.
System
Click to expand Rubric-scored quality gates for AI-generated artifacts
A rubric-and-judge architecture that scores every AI-generated artifact before it ships. The judge reads the artifact, scores against a rubric, blocks the ones that fail. Fixture regression catches when the bar drifts week over week.
The workflow that wasn’t happening: AI-generated artifacts (proposals, reports, emails, briefs) ship as fast as you can prompt. The quality bar drifts silently. By the time a regression is noticed, it has already gone in front of clients. Spot-checking by reading every artifact yourself defeats the productivity gain AI was supposed to deliver. Trusting the model to self-evaluate at write-time is the failure mode this system exists to catch.
What I built: a rubric-driven evaluation harness with a judge agent. Every artifact gets scored against a per-skill rubric (specificity, voice, formatting, banned-phrase scan, factual grounding). Failures gate the output before it reaches the operator. Fixtures hold the bar at snapshots of approved past work; regression against fixtures catches drift week over week. A weekly calibration pre-grades drafts blind to track agreement between the operator and the judge. The whole stack runs inline, not after the fact.
What it doesScores every AI-generated artifact against a per-skill rubric before it reaches the operator. Blocks failures. Logs scores for trend analysis.
What it savesThe four-figure trust loss when a client receives an AI-shaped output. The productivity hit of operator-as-grader.
Who runs itThe judge runs inline on every skill invocation. Operator sees scores and surfaced deviations in artifact metadata. No additional surface to log into.
The pattern translates to: any operator running production AI at scale who cannot read every artifact themselves. Service businesses generating client-facing copy at volume. SaaS teams shipping AI features into the product. Internal ops generating reports off LLMs. The eval harness is the QA layer; the rubric is the contract; the fixtures hold the bar.
Methodology
Click to expand A locked brand kit ported to production without spec drift
A three-gate port methodology that takes a locked brand kit to a live production site without spec drift. Used across four production sites without per-project carve-outs.
The workflow that wasn’t happening: brand kits live in mockup files. Production sites get built from those mockups. Almost always, the live site drifts away from the kit, often in the first week, sometimes during the initial port. Designers re-issue revisions. Engineers fight one-off changes. Six months later the live site barely resembles the kit and the kit has been re-issued three times. The methodology that prevents this is the work nobody wants to do until they’ve watched it fail twice.
What I built: a three-gate port that takes a locked brand kit to a live production site without spec drift. Gate A is design tokens (colors, type stack, spacing) declared in CSS variables and a TypeScript source of truth, before any component renders. Gate B is the monolithic homepage rendered against tokens and verified visually against the kit’s mockup, with copy verbatim from the locked voice doc. Gate C is component extraction from the monolith into a library, with audits on every commit, SEO and GEO shipping with each route, and reviewers running mid-build rather than at the end.
What it doesTakes a brand kit to a production site without the visual drift that usually creeps in between mockup and code. Three gates run in order; skip one and the work reverts.
What it savesThe compounding re-issue cycle as the live site and the kit fall out of sync. The trust loss when a client sees a site that doesn’t match the kit they approved.
Who runs itMe as the porter. The brand kit is the contract; the audits gate every commit. Used across four production sites without per-project carve-outs.
The pattern translates to: any operator who ships brand-driven products from locked design specs and watches the implementation drift. Brand-led founders carrying the kit themselves. Design teams handing off to engineering teams that don’t speak design fluently. Solo operators owning both sides who lose the kit’s coherence under deadline pressure. Same shape: the kit is the contract, the methodology is the audit trail.
Architecture
Click to expand Production discipline for agentic recipes that run unattended
The engineering posture that keeps agentic recipes from double-firing or blowing past budget while running unattended. Idempotency ledger, USD cost caps, nightly smoke probes, audit trail.
The workflow that wasn’t happening: agentic recipes call external systems. They send emails. They post webhooks. They pay for API calls. Without engineering discipline, the first retry double-fires a notification, the second recipe loop drives the bill past budget, and the third unattended run silently fails in production until someone notices the dashboard isn’t updating. Most agentic systems ship to production without the discipline that catches these failure modes.
What I built: an engineering posture baked into every recipe that talks to external systems. An idempotency ledger records every side effect (every email, every webhook, every paid API call) with a deterministic key, so retries don’t double-fire. USD cost caps enforce stopWhen budgets per recipe; the loop halts before the bill ticks past the ceiling. Nightly smoke probes run a synthetic version of each production recipe and fail loud when the contract breaks. An audit trail logs every action with recipe ID, idempotency key, and cost incurred.
What it doesPrevents double-fires on side effects. Caps USD spend per recipe. Runs nightly health checks. Audit-trails every action.
What it savesThe trust loss when a client sees a duplicate email. The four-figure overage from a runaway recipe loop. The silent-failure window when a broken recipe runs for days before anyone notices.
Who runs itThe engineering posture runs inline on every recipe. Operator sees cost charts and health-check status without logging in.
The pattern translates to: any operator running production AI that touches external systems. Recipes that send customer-facing email at volume. Agentic loops that call paid APIs. Scheduled jobs that need to fail loud, not silent. Most AI systems shipped today have none of these guardrails; the cost shows up in trust loss or budget overruns months later.
WorkspaceClick to expandnailfile.app
Visual asset libraries that are searchable, priceable, postable
A workflow app that turns a sprawling visual library into a managed, queryable corpus. Auto-tagging on every upload, vision-driven assessments, one-click routing to social.
The workflow that wasn’t happening: every organization with a sprawling visual library has the same problem. The photos exist on phones, drives, clouds, hard drives. Putting them to use is a manual lift every time. Finding the right one means scrolling through thousands. Assessing what’s in them takes someone looking at each. Posting them anywhere means digging through the pile by hand.
What I built: a workflow app that turns a visual library into a managed, queryable corpus. Auto-tagging on every upload by what’s visible in the image. Vision-driven descriptions make the library searchable. The same vision pass drives assessments (pricing a service from what’s in the photo, condition assessments for inventory). From the same library, assets route to social posts in a click. First built for NailFile. The pattern translates immediately.
What it doesSearchable (vision-tagged corpus). Priceable (vision-driven assessments). Postable (direct routing to social and external use).
What it savesHours of manual hunting through photos. The DM-and-text chaos for incoming references. The repeated lift of “find a photo, assess it, post it.”
Who runs itThe asset owner. In production with NailFile. Ready to deploy in adjacent verticals on Day 1.
The pattern translates to: product manufacturers with sales and lifestyle photography across multiple SKUs and channels. Distributors with inventory photography that needs to be priceable and listable. Real estate firms with inspection and listing libraries. Multi-location service businesses where brand photography is owned by different operators. NailFile is the first vertical; the operating shape is the same in a 200-person regional company.
CRMClick to expand
Two operational systems the board didn’t have before
Two spreadsheet-backed systems for a working 16-person board: a branded public resource library, and a sponsorship and partnership CRM with auto-generated research briefs on every prospect. Neither capability existed before.
The workflow that wasn’t happening: On Purpose Oregon is a regional nonprofit supporting business as a force for good, run by a paid Executive Director and a working 16-person board. The board wanted a polished resource library on the public site for members, and a shared way to track sponsorship and partnership prospects with research on each one and a record of who’d been in contact. Neither existed. Neither was being managed. The ED was leading the org; the board was carrying the operational work between meetings. What didn’t exist was the tooling to make either project runnable without an ops coordinator the org doesn’t have.
What I built: two spreadsheet-backed systems. (1) A branded resource library on the public site that reads from a board-maintained Drive spreadsheet. The board adds links in the sheet; the site renders them as a polished, well-maintained library. (2) A sponsorship and partnership dashboard that auto-generates enriched research briefs on every prospect and includes a built-in CRM the whole board uses to track communications. The spreadsheets are the substrate. The systems are what got built on top.
What it doesReplaces two missing operational capabilities with running systems the board can actually use. Externally, the resource library presents as polished and current. Internally, the partnership work is now ownable because it has a place to live.
What it savesThe cost of an ops coordinator the org doesn’t have a budget for. The opportunity cost of resources and partnerships that simply weren’t being curated or pursued.
Who runs itThe board. Resource library updates happen in the spreadsheet. Partnership outreach happens in the CRM. Both run without anyone learning a new tool.
The pattern translates to: any organization running real operational work but without the staff to hire ops coordinators. Working boards with paid leadership but no ops staff. Family-owned businesses where leadership runs strategy but no one runs operations. Small nonprofits with under-resourced development functions. Boutique partnerships with no BD lead. The spreadsheet is the substrate; the system is what gets built on top.
Engine
Click to expand An opportunity engine for consultants who serve nonprofits
An opportunity engine built for the consultant juggling multiple nonprofit clients. It scans grant databases and RFP sources across every client at once, then finds and argues the true match between a client and a funder, or tells you there isn’t one. Drafts are grounded in the client’s real facts, ready for you to finish.
The workflow that wasn’t happening: a consultant serving five nonprofits can’t scan grant databases weekly for each one, match every opportunity against each client’s real profile, and draft applications on top of the actual client work. So opportunities the clients could win go unfound, and the ones that do surface go unapplied because nobody has time to draft them.
What I built: an opportunity engine built for the consultant, not the nonprofit. It loads three to N clients and scans grant databases and RFP sources across all of them daily. The part that matters: it finds and argues the true match between a client and a funder, honestly, or says there isn’t one. It does not invent a fundable-looking story to force a fit. Drafts are grounded in the client’s real facts and program history, it flags what it doesn’t know instead of guessing, and it hands a submittable first draft to the consultant to finish. Grant applications go out under a real name, so the human stays in the loop by design. The doctrine was derived from a real submission for On Purpose Oregon, the first client it was proven against.
What it doesScans opportunities across every nonprofit client at once, argues the true funder match or rejects it, and drafts a grounded first application for review.
What it savesThe staff position no consulting practice can spare per client. The lost revenue from opportunities nobody had time to find or apply for.
Who runs itThe consultant, across their whole client roster. Drafts land ready for a final human pass, never auto-submitted.
The pattern translates to: any professional who scans opportunities on behalf of multiple clients and can’t clone themselves to do it. Grant consultants carrying a roster of nonprofits. Development shops pursuing funders for several orgs. BD leads chasing RFPs across a portfolio. The engine does the finding and the honest first draft; the human keeps the judgment.
System
Click to expand An operating system for a one-person resale business
A full sell-side system for a solo collector-goods reseller. Scan an item and it identifies the piece, prices it against live market data, and lists it to a custom-built storefront. A weekly intelligence email tells the operator what to sell, hold, or watch next.
The workflow that wasn’t happening: a solo reseller with hundreds of collectibles can’t identify each piece, price it against a moving market, list it, and still know which items to move now versus hold. The cataloging alone is a part-time job; the market timing is guesswork.
What I built: a full operating system for a one-person resale business, in three connected parts. A scan-and-price app: photograph an item, computer vision identifies the exact piece, and it prices against live marketplace data. A custom-built storefront, hand-coded rather than dropped from a template, that the app publishes listings straight into. And a weekly intelligence email that reads the market and tells the operator what to sell, hold, or watch. The whole business runs from a phone.
What it doesIdentifies, prices, and lists each item, and sends a weekly read on what to sell, hold, or watch, all from a phone.
What it savesThe part-time cataloging job and the guesswork on market timing. A back office a solo reseller could never staff.
Who runs itThe operator, solo. Scan to storefront to weekly intelligence, one person running the whole business.
The pattern translates to: any solo operator selling into a moving resale market. Collectible dealers pricing against live comps. Independent sellers who catalog by hand. Reseller side-businesses that need a back office they can’t hire for. The system does the identification, the pricing, and the timing; the operator keeps the taste.
System
Click to expand Branded client collateral, drafted from a single transcript
Built for The Impact Collective. It takes a transcript and generates the firm’s client collateral, a proposal, a one-pager, an email, matched to the firm both visually and in voice. It also keeps an internal library of the attachments the firm reuses, so repeat pieces are pulled, not rewritten. A judge scores each draft against the brand rubric before it ships.
The workflow that wasn’t happening: a consulting firm’s proposals, one-pagers, and emails all have to sound like the firm and look like the firm, every time. By hand that means a senior person writing each one slowly, or junior drafts that drift off brand. And the standard attachments the firm sends on every deal get rebuilt or hunted down each time.
What I built: a system for The Impact Collective that turns a transcript, a client call or discovery conversation, into the firm’s branded client collateral. It generates a proposal, a one-pager, and an email, each matched to the firm’s brand both visually and in voice, not just the wording. And it maintains an internal library of the attachments the firm reuses, so repeat collateral is pulled from one place instead of rebuilt every deal. A judge scores each draft against the brand rubric before it ships.
What it doesTurns one transcript into a proposal, a one-pager, and an email, each on brand in look and voice, plus a library of reusable attachments.
What it savesThe senior-writer bottleneck and the off-brand-junior-draft tradeoff. The scramble to rebuild the same attachments every deal.
Who runs itThe consultant. Input a transcript, get client-ready collateral that already matches the firm.
The pattern translates to: any firm whose sales collateral has to stay on brand while the volume grows. Boutique consultancies drafting proposals per client. Agencies producing one-pagers and decks at pace. Professional-services teams whose brand consistency is the product. The system holds the brand; the human brings the judgment.
DashboardClick to expand
One place for a board’s whole operation, nothing re-keyed by hand
On Purpose Oregon’s board ran its operation across a stack of multi-tab spreadsheets, each edited by a different person, plus three separate tools. This dashboard pulls all of it into one place automatically, so a board member signs in and immediately sees what needs their attention, and no one re-keys or reconciles the same numbers across systems.
The workflow that wasn’t happening: On Purpose Oregon is a working nonprofit board with no operations staff. The information that ran the org lived across many spreadsheets, each with multiple tabs, each maintained by a different board member, plus three separate platforms. No one had a single view of where things stood, and keeping any of it usable meant somebody re-typing numbers by hand from one place to another.
What I built: one dashboard that pulls every one of those sources into a single place automatically, so no one re-keys or reconciles the same numbers across systems. The scattered spreadsheets, their many tabs, and the three other tools all feed in on their own. A board member signs in and immediately sees what needs their attention this quarter: which members to check in with, how the numbers are tracking, what has happened recently. Member check-ins, the activity log, impact metrics, and the sponsorship pipeline all live in one hub instead of separate files nobody could reconcile.
What it doesPulls a board’s scattered spreadsheets and three other tools into one dashboard, with nothing re-keyed by hand across sources, and surfaces what each board member needs to do.
What it savesThe reconciliation nobody had time for and the re-keying of the same numbers across files and tools. The ops coordinator a volunteer board can’t hire.
Who runs itThe board. Everyone signs in to their own view; the data assembles itself.
The pattern translates to:any organization whose real operating information is scattered across spreadsheets and tools that different people own. Working boards with no ops staff. Family businesses running on a dozen shared sheets. Small teams where the “system” is a pile of files and a few apps nobody has reconciled. The dashboard becomes the single place; the sources feed it without anyone re-entering a thing.