Position Builder Pre-Alpha: Why I Scrapped the Old Stack and Rebuilt on Vercel

What the old stack looked like

The previous version of Position Builder used Supabase for the database and Cloudflare D1 for parts of the data layer. Auth was handled separately. Cron jobs were pointed at API routes through an external scheduler. Nothing was broken exactly, but nothing was cohesive either.

In practice, that meant four or five places to check when something went wrong. It meant manually reconciling credentials when the environment changed. It meant that adding a new integration involved deciding which of several systems it belonged to — a question that should not need to be asked at this stage of a product. For most apps, that kind of friction is manageable. For a fintech product, where you are already tracking brokerage credentials, OAuth tokens, and user account state, it is a liability.

Why I decided to rebuild instead of patch

The honest answer is that I kept running into the same five minutes of setup friction every time I switched contexts. Pulling credentials, reconciling what lived where, checking which service was responsible for which part of the auth flow. That friction compounds.

The cleaner answer is that the foundation was not designed for what the product had become. Position Builder is an automation platform for equity and crypto microfolios built on top of a real broker API. That means real KYC requirements, real order execution, real audit trails. The original stack was built for a prototype. Once I was serious about the product, I needed infrastructure that matched the operational requirements — not one I had to work around.

The Vercel Marketplace pattern and why it matters for fintech

The core of the rebuild was choosing Neon Postgres and Clerk through Vercel Marketplace instead of managing them independently. That might sound like a minor convenience decision. For a fintech founder, it is an operational one.

When you provision Neon or Clerk through the Vercel Marketplace, those services inject their environment variables directly into your Vercel project. They show up in the same dashboard as your deployments. They share the same billing surface. And the consequence of all that is simple: vercel env pull .env.local gives you everything you need to run locally, without touching a separate Supabase dashboard, a separate auth provider console, or a separate credential store.

Clerk also ships with keyless mode for local development, which means you do not need to add Clerk API keys to .env.local at all during development. The service handles local auth automatically. That is the kind of zero-friction default that matters when you are moving fast and do not want credential management to be something you think about.

• Neon and Clerk provisioned through Vercel Marketplace — env vars injected automatically, no manual wiring.
• Single billing surface across database, auth, hosting, and cron.
• Clerk keyless mode eliminates local dev credential setup entirely.
• One dashboard to watch when something breaks in production.

What Vercel Cron replaced and why it is the right shape

The automation core of Position Builder needs to run every five minutes: check which user strategies are due, execute avg-down or take-profit logic against their Alpaca positions, and write results to the audit log. That requires a reliable, always-on scheduler.

Previously, that scheduler lived outside the platform. Now it is a single entry in vercel.json, a protected endpoint secured with CRON_SECRET, and a serverless function that Vercel calls on schedule. Failures surface in the same log view as every other deployment event. There is no separate scheduler dashboard to watch, no external service to keep in sync with your deployment lifecycle.

For a fintech automation product specifically, that shape is important. When a cron job does not fire, you need to know immediately and in context. A log that lives in the same place as your deployment history, your function errors, and your environment config is operationally much cleaner than one that lives in a third-party scheduler interface you check separately.

The automation engine itself

The engine that runs inside that cron job is doing real work. Every five minutes it queries Neon for strategies where enabled is true and nextRunAt is in the past, then processes each one against live Alpaca Broker API positions.

The logic covers avg-down buys when a position dips below threshold, auto-sell and take-profit triggers, re-entry rules after a liquidation, and market hours enforcement that is DST-aware — equity orders are gated to weekday extended hours in ET, not a hardcoded UTC offset. Every action writes a row to symbol_snapshots, which serves as the full audit trail for the account.

For fintech founders, the audit trail part is not optional. If you are executing trades on behalf of users, you need a complete record of what ran, when, why, and what the outcome was. Drizzle ORM on Neon made that straightforward to model and query without the overhead of a heavier ORM or a separate event-sourcing system.

• Avg-down, auto-sell, take-profit, and re-entry strategies per symbol per microfolio.
• DST-aware Eastern Time market hours enforcement — no hardcoded UTC offsets.
• Full audit trail in symbol_snapshots for every automated action.
• Manual trigger available alongside the scheduled cron for testing and override.

KYC onboarding and what it took to get right

Alpaca Broker API has a real KYC requirement. You cannot create a broker account without a full set of identity data: name, address, SSN, date of birth, employment information, investment experience. The onboarding form has to collect all of that and submit it correctly — not approximately correctly.

The first production run surfaced a few things fast. OAuth token fetches were failing because the Alpaca token endpoint expects client_credentials body params, not API key headers — the naming overlap between ALPACA_API_KEY and ALPACA_CLIENT_ID is a real trap. Duplicate account creation was throwing 409 errors without a fallback to look up the existing account by email. SSN formatting needed to match the XXX-XX-XXXX pattern exactly before submission.

Once the submission side was stable, the UX needed work. Auto-formatting SSN and phone as the user types, a country code picker so users enter a local number without guessing dial codes, client-side validation for 18-plus DOB and valid US state, and human-readable error messages when Alpaca rejects a submission instead of surfacing raw API JSON.

This is the part of fintech that does not get shorter as the product matures. Regulatory requirements do not shrink. The right investment is designing your onboarding to absorb that complexity on behalf of the user — not to pass it through.

Proxied document downloads and why Alpaca tokens stay server-side

One of the last things I shipped before calling this pre-alpha was a documents page: account statements, tax documents, trade confirmations, and agreements pulled from Alpaca Broker API and surfaced in the dashboard.

The download flow is proxied through a server-side route handler. Alpaca tokens never leave the server. The client gets a signed response, not a URL with credentials embedded in it. In Next.js App Router, this is a clean pattern — a server component fetches the document list, and a route handler streams individual file downloads. No token exposure, no client-side credential access.

For fintech specifically, this is not a nice-to-have. It is a default. If you are building on top of a broker API, brokerage credentials belong on the server. Every surface that does not follow that rule is a potential incident.

What pre-alpha actually means for a fintech product

Pre-alpha in consumer apps usually means rough UI and missing features. Pre-alpha in fintech means something more specific: real brokerage infrastructure, real KYC, real regulatory compliance hooks — but limited user surface, sandbox API, and no production trading volume yet.

The stack decisions at this stage compound harder than in consumer apps because you are not just choosing tools. You are choosing your operational model for when things go wrong — and in fintech, things eventually go wrong at exactly the wrong moment. A cron job that does not fire on a volatile market morning. An OAuth token that expires mid-session. A duplicate account submission that surfaces in production but not in sandbox.

What the Vercel-native rebuild gave me was a single operational model across all of those surfaces. One place to look when something breaks. One command to get credentials. One billing account when costs need to be tracked. That is not glamorous, but it is the right foundation for a product that is going to ask users to connect real brokerage accounts to automated trading strategies.