Forem: Build Wright

Day 18: Free First. Why I Am Launching FinancePulse Without a Paywall.

Build Wright — Fri, 08 May 2026 19:57:04 +0000

Day 18: Free First. Why I Am Launching FinancePulse Without a Paywall.

Day 18 since I incorporated Northvane LLC and started the Build Wright public clock. Today is Friday, May 8, 2026. Three weeks ago none of this existed. This week shipped a lot, and the shape of the next 4 weeks is now clear enough that I can stop guessing and start sequencing.

Quick honest framing before I get into it: nothing I describe below is "validated" in the revenue sense yet. The Quick Start Guide has a handful of buyers. FinancePulse has zero subscribers because the signup form was live for 36 hours. PatentScan is still on the napkin. So this is a build-in-public update, not a victory lap.

What shipped this week

Three things landed.

Two open source repos. I had been carrying a Stripe webhook signature verifier and a Supabase RLS cookbook around in my own head for weeks. Both are the kind of thing every solo SaaS founder reinvents badly the first time. So I extracted them into standalone repos and pushed them to GitHub. The webhook verifier is a tiny zero-dependency npm package that does one thing well: validates the Stripe-Signature header against a raw request body and rejects replay attempts past the SDK's default 5-minute tolerance window. The RLS cookbook is a long-form documentation repo with copy-pasteable patterns for the four ways I have personally screwed up Supabase row-level security and then had to debug at midnight. Neither will go viral. Both will help me show up on AI-search answers when somebody types "how do I verify stripe webhook signature" into Claude or ChatGPT or Perplexity, which is most of how I expect to get found in the next 12 months.

FinancePulse free digest pipeline. The bigger lift. I rewrote financepulse.app around a free utility instead of a paid report. The pivot is documented in the previous article. What landed this week:

A SEC EDGAR scraper that pulls the recent Form 4 filings feed every weekday after market close, parses each filing's ownership document XML, and stores the open-market purchases in Postgres.
A cluster detector that flags two patterns: 3 or more distinct insiders buying the same ticker inside a 5-day window, and isolated single buys above $500K.
A daily digest email rendered per subscriber, with HMAC-signed unsubscribe links and a Tuesday-first cadence that respects the no-spam rule.
The whole subscribe and unsubscribe flow including welcome email, with a free signup form at financepulse.app.

The first real digest sends next week, Tuesday May 12, after I have one full data-collection cycle to confirm the pipeline produces something worth reading. Until then it is plumbing.

Why free first

The original FinancePulse plan was three paid PDF reports at $29 to $49 each, fulfillable on demand. That plan died for the same reason a lot of cold-launch paid-report ideas die: you have to spend audience to get audience, and I do not have audience yet.

So the question is: what do I have time and code to give away that is good enough to pull people back tomorrow? The answer turned out to be the daily insider buying digest. The data is public, the work is in the aggregation and the writeup, and the reader gets actual signal in their inbox before they have to decide if they like me. That is the free-utility-first calculus. If the digest is good and the open rate stays above 25 percent at week 4, the paid tier becomes a much easier conversation. If it does not, I learned that the audience does not actually want this, which is also worth knowing before I spend 8 weeks building a paid product on top.

The paid tier is still coming. Not in two months. Tuesday Day 22, May 12. A $29 deep-dive report on a single ticker, plus a $9 per month Pro subscription with a 10-symbol watchlist and SMS alerts on the same cluster patterns. Both ride on infrastructure that is already built. The free digest is the front door, and the paid tier is the answer to "OK this is useful, can I have more of it specifically about my portfolio."

The multi-brand architecture decisions I am locking in

I am running three brands now: BuildEngine, FinancePulse, and a third (PatentScan) that launches later this month. Three different niches, three different audiences, one operator. The infrastructure choices below have come up in every brand and I am settling them once so I do not relitigate them per project.

Separate Supabase project per brand. This was tempting to consolidate. One database, schema-namespaced tables, row-level security as the tenant boundary. I tried that mentally for an afternoon and then walked away. The blast radius of a bad migration on a shared cluster is too high, the cost of a separate project is twenty-five dollars per month, and the mental separation when I am writing migrations at 11pm is worth more than the savings. So: financepulse-prod, buildengine-prod, patentscan-prod, full isolation, zero cross-brand queries. If I ever need a portfolio dashboard, I will do it via per-brand HTTP queries from a coordinator, not via a shared schema.

Shared Resend account, multi-domain verified senders. Resend handles the cross-brand send volume cleanly because it lets a single account verify multiple sender domains. So hello@buildengine.tech, hello@financepulse.tech, and hello@patentscan.io all live in one account, with separate API keys per brand and separate audiences for unsubscribe segregation. This is the opposite of the database decision and it is also right for the same underlying reason: deliverability reputation is built per-domain regardless of account, and consolidating accounts does not pollute reputations. Centralized control, isolated trust.

One Stripe account, metadata-tagged products. Stripe is the inverse of Supabase. There is real value in having all revenue in one place for accounting (Northvane LLC is the legal merchant for everything), and the per-product metadata.brand tag is enough to filter reports per brand. The customer sees the brand statement descriptor on their card, the IRS sees Northvane LLC.

The pattern I am settling on across all three: isolate where mistakes are expensive, consolidate where mistakes are cheap. Database migrations are expensive. Sender reputation is expensive. Accounting is cheap.

What broke and what I learned

EDGAR Form 4 detection. First fix used the type field in SEC's directory JSON to identify the primary Form 4 XML. Reasonable assumption. Wrong. The type field in the production payload turned out to be display-class labels like text.gif, not form codes. So my filter rejected every real filing on the first cron run. The corrected version matches by filename pattern (ownership.xml, primary_doc.xml, and a few legacy variants), then verifies by parsing and checking the <documentType> element. Lesson: if you are integrating with a government API, do not trust your assumption about a field's semantics until you have seen the actual payload from production. I had three synthetic fixtures, all wrong about that field.

Vercel apex vs www domain redirect. Spent an hour on a 308 redirect loop between financepulse.app and www.financepulse.app. The fix was to set the apex as the canonical and let Vercel handle the www-to-apex redirect at the platform level instead of trying to do it in a middleware. Boring, but I had not hit it before because all my other domains had been www-only from the start.

Hashnode AutoMod silent removals. Two of the four platforms I am syndicating to (Bluesky, Mastodon, Dev.to, Hashnode) are reliable. Hashnode is the one I cannot fully trust yet. Twice now an article has shown a successful API response, then quietly disappeared from the feed within an hour. The article is technically live at the canonical URL, just delisted from discovery. No notification, no email. I am keeping the syndication for SEO link equity but I have stopped counting Hashnode reach in any metric that matters.

What is coming the next two weeks

Tuesday Day 22, May 12. First real FinancePulse digest sends. Same day, paid tier opens: $29 per-ticker report + $9 per month Pro subscription with watchlist and SMS alerts.
Friday Day 25, May 15. PatentScan landing page goes up. Free weekly USPTO grant digest in the same shape as FinancePulse, with a paid weekly deep-dive at $19 per report.
Day 28, May 18. Quick Start Guide v1.3, with a section on the multi-brand operator architecture I just described above.

Three brands, one operator, three different "what is the daily reason to come back" questions answered. If two of the three free digests retain readers at week 4, the playbook is real. If one of them does, I have a winner and two lessons. Either is fine. What is not fine is launching a fourth thing before I see what these do.

If you want the free digest, it is at financepulse.app. One tap, no card, unsubscribe at the bottom of every email.

If you want the operator playbook in long form, the BuildEngine Quick Start Guide is $49 and has been the cleanest signal so far that the writing is doing its job. Buyers have come from articles, not ads.

Build Wright

I open-sourced the Stripe webhook verifier I built for Next.js 15

Build Wright — Wed, 06 May 2026 15:40:12 +0000

The problem

I shipped my first SaaS a few weeks ago. Stripe webhooks were one of the things that took longer than they should have, because the official Stripe documentation example breaks in Next.js 15 App Router.

The issue is how App Router reads request bodies: The standard pattern in older Next.js used req.body directly. App Router uses request.text() and the body can only be consumed once, which trips up the standard Stripe verification flow if you read the body for any reason before passing it to the verifier.

I solved it for myself, then realized other people were probably hitting the same wall. So I extracted what I built into a standalone package.

What it is

@northvane/stripe-webhook-verifier-nextjs

A type-safe Stripe webhook signature verifier for Next.js 15 App Router, with structured failure reasons so you can tell the difference between "wrong signature" and "expired timestamp" and "malformed header" without parsing error strings.

MIT license
19 unit tests covering forged signatures, replay attacks, body tampering, malformed headers, edge cases
Zero dependencies beyond the Stripe SDK (which you already have)
Returns a typed Stripe.Event on success, or a structured failure with a specific reason on failure

Quick example

import { verifyStripeWebhook } from '@northvane/stripe-webhook-verifier-nextjs';
import { NextRequest } from 'next/server';

export async function POST(request: NextRequest) {
  const body = await request.text();
  const signature = request.headers.get('stripe-signature');

  const result = verifyStripeWebhook({
    body,
    signature,
    signingSecret: process.env.STRIPE_WEBHOOK_SECRET!,
  });

  if (!result.ok) {
    return new Response(`Webhook error: ${result.reason}`, { status: 400 });
  }

  // result.event is a typed Stripe.Event
  switch (result.event.type) {
    case 'checkout.session.completed':
      // handle
      break;
  }

  return new Response('ok');
}

Common pitfalls this addresses

Body parsing in App Router. If you read request.json() or request.text() more than once, the second call returns empty. The package documents the right pattern.
Stale signing secret rotation. Stripe lets you rotate webhook signing secrets, but if you cache the secret in module scope, you keep verifying against the old one. The package recommends reading from env vars per-request.
Timestamp tolerance defaults. Stripe's default tolerance is 5 minutes, which protects against replay attacks. The package surfaces this as a structured failure (reason: 'replay') so you can log and alert separately from "wrong signature" failures.
Documented quirk: Stripe's tolerance check only rejects signatures from the past, not the future. Far-future timestamps pass verification. The package documents this so you're not surprised.

Get it

Repo: https://github.com/aibuildwright/stripe-webhook-verifier-nextjs

Issues, PRs, and feedback welcome. This is the first of several utilities I'm extracting from my own SaaS launch and open-sourcing while building BuildEngine in semi-public.

If you've hit similar webhook issues or are about to build your first Stripe integration, I'd love to hear what bit you.

Day 15: Why I Pivoted BuildEngine. The API Pricing Wall.

Build Wright — Wed, 06 May 2026 03:13:25 +0000

Day 15: I already had to do a hard pivot. The API pricing wall.

Two weeks ago I began the journey of BuildEngine. The goal was simple, to use AI tools to assist in building successful businesses, and to teach others how to do the same using my methods, lessons, and eventually software stack. Eleven days later I completed and posted BuildEngine's Quick Start Guide for sale. And the very next day I had to pivot the entire strategy.

This is what happened…

The original plan

Everything seemed very straightforward on paper. I would build AI-assisted business, document the journey along with every misstep, instruction, and correction, and then start with a $49 Quick Start Guide. Later, I would bring in subscription products: a $69/month "AI Business Operator" tier giving solo founders an inside look into how I am running my businesses and the strategies, revenue, and guidance that a multi-business dashboard and a set of comprehensive instruction doc would provide. Then, higher tier of "TractionKit", that would allow a solo founder to get multiple tools to run their businesses in a similar way.

The operator tier was the entry point. Hey, I would run my own businesses with these tools, prove they work, then sell them to other solo founders for the same job. Build it, dogfood it, and then license them out to help others after showing that anyone can use AI to become a founder.

However, the tools depended on several external data sources. Reddit for community engagement intelligence, ProductHunt for launch trend signals, and Twitter for engaging and building an audience.

I had infrastructure assumptions for each of these, and they were all wrong. The big issue: I planned most of it with AI, and AI can (and will) make mistakes.

The first wall

Reddit's commercial API access requires written approval from Reddit for any commercial use, as opposed to earlier times where it was relatively open. I learned this on Day 14, after my new account got auto-removed from r/SideProject by Reddit's spam filter. I read the actual Data API Terms of Service for the first time. The clause makes it clear. And furthermore, the site doesn't even let you post until you build up a sufficient amount of karma.

The application takes 1-7 days to review with no guarantees of success. ProductHunt's API requires similar approval. Both are explicit that "personal projects monetized later" still counts as commercial use, creating a massive stumbling block.

Strike one.

The second wall

No worries, I would just move to Twitter/X and get it done there. Right? A $100/month subscription tier gets you 60 search requests per 15 minutes, enough for my needs. Or at least Claude told me.

So I went to register, and learned about a huge change in February 2026. Twitter killed all fixed cost subscription tiers. The new model is pay-per-use: $0.005 per post read, and $0.010 per post created. For my planned scope (scanning ~3,600 keyword searches per month plus polling 30 accounts at 5-15 minute intervals), the math works out to $750-1,000 per month.

Son of a…!

Now the unit economics were in the gutter. My Quick Start Guide is $49. I'd need 15-20 sales every month just to cover Twitter API calls alone, before any infrastructure/Claude/API costs, and to cover my time.

And the real kicker is that I was relying on that as a sales channel to actually connect with potential customers! So paying such an amount to try to build audience, to try to make sales, to cover the API costs, make little sense.

Strike two

The third wall

I tried to fall back to the platforms where I could engage with no paid API. But of course Hacker News restricted Show HN posts on new accounts: "massive influx, become a contributor first." Indie Hackers requires a large comment history or a $198/year membership to post.

Let's summarize: Twitter API priced me out. Reddit gated me out. ProductHunt gated me out. Show HN gated me out. Indie Hackers gated me out. Five distribution channels, all that I was counting on and would not be possible to use.

Strike three.

At this point, I realized I was out, and that I could either 1) give up or 2) pivot. Giving up is never an option.

The reframe

Here's what I thought about when trying to optimize around these constraints: Every solo founder hits this wall.

Whether it is saturated channels, gated communities or the pain of shouting out into the void of a new Twitter account. APIs that used to be cheap and open are now expensive and closed. And paid ads on places like Meta and Google, well far too many solo founders have had negative ROI. The best platforms to use know that they are in a position of leverage, and have priced their tools and gated their walls (although the last is actually wise so AI bots don't run rampant). So ironically, the platforms that solo founders need to reach are the ones least open to new operators.

The original BuildEngine would sell tools that work IF you have an audience. But solo founders without revenue can't afford the tools that build the audience.

That gap is the actual product.

The pivot

BuildEngine's product positioning is now: the Organic Distribution Stack for solo founders without paid ads.

The same tools I was building for myself, which are now called Comment Interceptor, Cross-Platform Article Syndicator, AI Search Visibility Tracker, GitHub Marketing Engine, Direct Outreach Pipeline, Stack Overflow Answer Discovery, Press Outreach Pipeline, Schema.org auto-optimizer, have become the product. Not "automation for running an AI-assisted business." Instead, tooling for finding signal in saturated channels and amplifying organic reach without paid ad spend.

The tools will work for any niche. I am dogfooding them across three brands simultaneously to prove this:

BuildEngine (live) - solo founder tooling and methodology
FinancePulse (relaunching as free utility first) - insider buying signal aggregation for retail stock and financial investors
PatentScan (new launch this month) - IP intelligence for legal and R&D professionals

Three different niches, three different audiences, one shared toolkit underneath. If the tools produce results in three unrelated categories, the value proposition is real. If they only work for one, I will learn something important and then decide if I need to drop one, start a new one, or do another pivot.

What I built this week

Even with the pivot, the week shipped. By Day 15:

Quick Start Guide v1.2 (77 pages, $49, live and selling on buildengine.tech)
Comment Interceptor for HackerNews, running on a daily cron, with AI-scored opportunity surfacing in two modes: sales (high-intent buyer threads) and karma_building (substantive engagement opportunities)
Schema.org structured data and llms.txt across the entire site, optimized for AI search assistant indexing
This article syndicated to Bluesky, Mastodon, Dev.to, and Hashnode via the new Cross-Platform Article Syndicator (the article you are reading is the first real-world test of that tool).

What did NOT ship: Idea Validator (which was scheduled for May 7, has now slipped to mid-May for these unfortunate reasons), a Reddit version Comment Interceptor (waiting on commercial API approval), the TractionKit subscription product (now slated for week 6-8 after the tools are developed and tested for at least 4 more weeks).

What is coming

The next four weeks of building will be, in rough order:

Finishing up the internal tools, testing them, and building them into a commercial product
FinancePulse: free daily insider digest will launch publicly
PatentScan: paid weekly USPTO grant digest will launch
Day-by-day articles every 5-7 days documenting numbers, friction, and what I learned

I'll be honest, I felt like throwing in the towel for about 2 seconds. Just a moment of feeling sorry for myself before asking "how do I course correct." And that is what being a founder is all about.

The Quick Start Guide is available for $49 now. TractionKit will open in about 6 weeks, with a special lifetime price for the first 25 customers when the tool launches.

On the pivot itself

I was in a huge hurry to do month's worth of work in weeks and made a rookie mistake, namely forgetting to double check assumptions. Moving forward with a plan when assuming that certain tiers of pricing or API usage has remained constant, or posting permissions is available, was a complete and utter mishap on my part.

But there is a silver lining here. I realized that any website can change TOS on you, increase their pricing or pull your access. So now BuildEngine is going to be very flexible, and is creating products that allow a solo founder to build without a large ad spend or API costs. That will be of tremendous value.

Build Wright

If you want updates on what I'm building, subscribe to the weekly brief.