The Context

Task apps are easy to start and easy to abandon. The opportunity was a tool built around reengagement at the moment of friction (what to do right after the last task closes) rather than another list that gets opened once and forgotten.

The constraint was ownership: no handoff between strategy and build. One person had to carry the product from architecture decisions through the exact wording on an App Store permissions screen.

The Strategy

I scoped a v1 around four mechanics that justified the app's existence rather than padding a feature list: Smart Refocus (automatically surfaces the next task on completion), Quiet Day (a reduced pace mode), Weekly Wrap (a completed tasks summary), and import/export against Todoist and Notion so switching cost wasn't a barrier.

On architecture, I made the call to build a unified BillingService abstraction spanning Stripe (web), StoreKit (iOS), and Play Billing (Android) against one entitlement schema, instead of three disconnected purchase paths that would each need separate QA and separate failure modes.

The Execution

I owned the end to end build and the launch strategy, while directing engineering on the one decision that mattered most for launch risk: purchase verification that fails closed, not open.

Store review requires precise permission and purchase handling. I enforced server side purchase verification through Apple JWS signature validation and Google Play Developer API token verification, so invalid credentials fail closed instead of granting access.

When Apple rejected the build under Guideline 5.1.1(iv) over the wording on a microphone permission priming screen, I traced it to a single button label implying the app, not the OS, was deciding on permission, corrected the copy, and cleared App Review within one cycle.

I ran the store compliance program directly: data safety declarations, age ratings, and permission hardening across both consoles, with broad international storefront availability. For launch strategy, I coordinated press outreach and built the Product Hunt launch so iOS and Android went public at the same moment.

The Outcome

Nextly is live and publicly downloadable on both the Apple App Store and Google Play. That is the bar I held for "launched," rather than a build merely sitting in TestFlight or internal testing.

The Context

Within that program, a real gap sat in the booking experience itself: recreators with disabilities had no reliable way to tell, before they booked, whether a campsite actually met their accessibility needs. Accessible camping was the feature I owned to close that gap.

Recreation.gov runs under an Authority to Operate: a federal security authorization renewed on a fixed cycle under FISMA and NIST aligned protocols. A lapse can suspend authorization for a national public platform, so renewal work had to remain visible in the delivery plan.

The Strategy

I drove the accessible camping feature as a product owner would: defining the accessibility data standard a campsite listing needed to carry (surface type, site grade, accessible table and fire ring clearance, distance to accessible restrooms), coordinating with land management agency stakeholders to validate those fields against real site conditions, and sequencing the rollout against the delivery team's sprint calendar.

I treated the surrounding ATO compliance cycle the same way, as a scheduling discipline rather than a paperwork exercise, with every renewal milestone worked backward into that same calendar so the feature work and the compliance work never competed for the same sprint.

The Execution

I owned accessible camping end to end: requirements, agency coordination, and the signoff a feature needs before it ships on a federal platform, while serving as the primary liaison between delivery teams and federal client stakeholders on everything else moving through the program.

I ran the requirements and acceptance sessions that turned agency accessibility standards into listing fields the delivery team could build, then tracked the feature through review and signoff. In parallel, I facilitated cross functional delivery and governance sessions, authored executive compliance briefings, and safeguarded confidential program and personnel records to federal standards.

The Outcome

Accessible camping shipped as a standing feature of the booking flow, giving recreators with disabilities accessibility data they can check before booking. Alongside it, the ATO renewal work I supported continued without a compliance lapse.

The Context

Most productivity systems built for ADHD still borrow the vocabulary of neurotypical discipline: streaks, leaderboards, guilt as a motivator. The market gap was a system designed around how ADHD attention actually fails (task initiation, object permanence for digital tasks, field count paralysis, working memory overload) without shame baked into the UI.

The Strategy

I built the product structure around three working principles, Energy, Focus, and Reset, expressed through a Notion based system (Today, Start Here, Parking Lot, Low Battery Mode, Weekly Reset) and a deliberate vocabulary: One Priority, Next Step, Drop a Thought, Proof not pressure.

Midway through the launch, I repriced from $47 to a $17 one time purchase and rebranded around "The Planner Autopsy," framing the product against six documented ADHD failure modes instead of generic productivity claims, which sharpened the pitch considerably.

The Execution

As founder, I owned product scope, brand, acquisition, and mobile development decisions, keeping the experience consistent from discovery through onboarding.

I wrote and shipped the sales copy, onboarding guide, and full PDF deliverable set; designed and ran the Meta Ads funnel (pixel, lead and purchase events, domain verification, business portfolio structure); and directed a Capacitor wrapped iOS/Android build of the product's core web app as a product director working with a build agent, not a dev team.

Every brand decision enforced the same rule throughout: no shame language, no streaks, no leaderboards. I held that constraint even when it meant turning down more conventional growth lever copy.

The Outcome

Live at commandcenteradhd.com with a defined acquisition funnel and documented customer feedback. The mobile apps are in development as the next release.

The Context

People rarely break commitments because they forgot making them. They break them because nothing happens in the gap between making the commitment and the deadline. Most task and reminder tools stop at capture and confirmation, then go quiet until the due date arrives and it's too late to adjust.

The opportunity was a system that stays engaged through the full life of a commitment instead of going silent after the first step.

The Strategy

I set a six stage loop as the product's spine: capture, confirm, watch, intervene, adapt, resolve. Every feature decision coming out of the build has to map onto one of those stages or it doesn't ship.

On brand, I rejected an earlier teal and IBM Plex Mono direction that read as generic utility software and directed the build toward an indigo and violet palette with Sora and Inter typography, a visual identity built to feel considered rather than default.

On monetization, I reversed an earlier plan for a one time purchase after confirming the build platform's managed billing integration couldn't support nonconsumable purchases, and set pricing at an annual subscription with a seven day free trial instead.

The Execution

I act as product director on every build decision coming out of the development agent: reviewing proposed flows against the six stage loop, approving brand direction, and setting monetization terms myself rather than deferring them.

The marketing site at kepvia.digital is separate from the mobile app. This keeps product information and support accessible while Android distribution and the Apple review process progress independently.

The Outcome

Kepvia is live on Google Play. The iOS version is awaiting Apple App Store approval. The next priority is to evaluate activation, commitment resolution, and repeat use following the Android release.

The Context

Independent filmmakers are underserved by the major streaming platforms, which are built around licensed catalog content, not a creator uploading and monetizing their own work directly to an audience. Lumavoya is being built to close that gap: a platform positioned specifically for independent film, not a general purpose video host repurposed for it.

The Strategy

My role here is advisory, not build owner: the product is being developed on the Emergent no code platform, and I review the UI/UX direction and the technical functionality coming out of that build against what an independent filmmaker and their audience actually need, rather than what's fastest to ship.

The catalog model I've reviewed is dual track on purpose: a flat $20 single title fee for anyone who wants one film, and a founding member tier for unlimited catalog access, so the platform doesn't force a subscription on a viewer who just wants to watch one thing. Content is organized around curation, not a wall of thumbnails: Award Winners, Staff Picks, and genre rails (drama, thriller, atmospheric mystery, documentary, art house romance, historical fiction, coastal drama), plus an open filmmaker submission path so the catalog can grow past what the team sources directly.

The Execution

I review UI/UX direction and technical functionality as Lumavoya moves through its build, giving the no code development process a product and filmmaker experience lens it wouldn't otherwise have.

One of the titles live in the catalog, "Devil in a Sundress," is credited to Eagle Africa Production, the film production company I manage jointly, alongside TRS Promotion, giving me a working filmmaker's view of the submission and listing experience I'm also reviewing as an advisor. This is a narrower mandate than my founder and product director roles elsewhere in this portfolio, and I keep it framed that way: advisory input into someone else's build, not ownership of the roadmap or the engineering decisions.

The Outcome

Lumavoya is live in preview with a working catalog, pay per title and founding membership checkout paths, and curated collections, with product and UX review ongoing ahead of a public launch.

The Context

Finance teams already have forecasting tools and AI copilots pitched at them constantly, and most CFOs' real objection isn't accuracy, it's control: nobody wants software quietly moving money or committing the business to a decision without a human in the loop. The opening for FinForceX wasn't "AI that predicts cash flow," every competitor claims that. It was AI that a finance team can actually trust to operate inside their business, because it can't act without permission.

The Strategy

I'm directing the build toward governance as the core product, not a compliance afterthought bolted onto a forecasting tool. Every AI output, a cash flow risk flag, a revenue opportunity, a recommendation to delay a vendor payment, routes through an explicit six stage lifecycle: Data Ingestion, AI Analysis, Insight, Recommendation, Approval, Execution. Nothing skips the Approval step, and a persistent "Pause All AI Actions" control sits one click away at all times.

Access is role based (CFO, Accountant, Partner) so the same underlying cash position surfaces differently depending on who's looking at it and what they're accountable for, and onboarding is sequenced around connecting real financial data, bank account, then accounting software, before any forecast is presented as something to act on.

The Execution

Autonomous intelligence with human authority isn't marketing copy here, it's the product's actual operating constraint: I review every build decision against whether it preserves that boundary, not just whether the feature works.

Built on the Emergent platform, the same build pattern I direct on Nextly and Kepvia. Integration sandboxes are live against Stripe and Bill.com, feeding a 90 day cash flow forecast, anomaly detection, and a revenue intelligence layer, with every AI action logged and reversible decisions surfaced before execution rather than after.

The Outcome

The sandbox demonstrates onboarding, role based dashboards, an AI Control Plane, and an approval queue. Displayed recommendations and financial amounts use demonstration data. Remaining work includes real bank and accounting connections and evaluation against live data before general availability.

The experience

Players observe scenes and conversations, choose their next move, and practise timing challenges. Campaign progression, Street Cred, and a safety journal connect individual encounters to a continuing experience.

Product decisions

Offline mobile play, local progress storage, and no account requirement keep the experience accessible without a continuous connection. Audio and reduced motion settings give players control over presentation. The game is free, with no ads or in app purchases.

Release and next milestone

The Android game is publicly available on Google Play. The next evidence to gather is scenario completion, usability, and player feedback. The release demonstrates delivery; learning outcomes and retention still need evaluation.

All encounters are fictional educational simulations. The game provides no emergency assistance or guarantee of real world safety.