DEV Community: Arek H

I Built a Full-Stack B2B Marketplace in 3 Days With V0, Next.js 16, and Vercel's AWS Integration — Here's What Actually Happened

Arek H — Sat, 27 Jun 2026 08:20:08 +0000

The honest account: what worked, what broke, and what I'd do differently.

Three days. One B2B Dutch-auction marketplace. Here's the realistic version of what building with V0, Next.js 16 App Router, Aurora PostgreSQL, and DynamoDB actually looks like when you're going fast.

This is not a "look how smooth AI coding is" post. It's the honest version.

The Stack

Frontend: Next.js 16 (App Router), Tailwind CSS, shadcn/ui, generated by V0
Backend: Next.js API routes, TypeScript
Databases: Aurora PostgreSQL (relational) + DynamoDB (atomic inventory)
Auth: Vercel OIDC Federation → AWS IAM (zero stored passwords)
Deployment: Vercel
AI tools: V0 for UI generation

V0: What It's Actually Good At

Let me start with the honest assessment. V0 is genuinely impressive at one specific thing: generating multi-page UI from a detailed prompt and producing something that's 70–80% of the way to production-quality on the first pass.

Here's the prompt structure that worked:

Build [app name]. DO NOT provision any databases.

WHAT IT DOES: [one paragraph, clear]
BUILD THESE PAGES: [numbered list, each with specific UI requirements]
DESIGN DIRECTION: [specific hex colors, font choices, component library]
DO NOT: [explicit list of what not to do]

The "DO NOT" section is not optional. V0 will try to add authentication, spin up a database, create server actions, and add 47 npm packages you didn't ask for if you don't explicitly forbid it. Write the constraint list first.

The result after one well-structured prompt:

Dark navy (#0a0f1e) background with amber (#f59e0b) pricing
4 pages with correct navigation
Correct shadcn/ui component usage
Countdown timers in monospace font
Low-stock red indicators
Crossed-out start prices + large current price display

Genuinely good output. The thing that V0 gets right is visual design decisions — the layout hierarchy, the card structure, the urgency indicators. These are the things that take hours to hand-craft and minutes to generate.

What V0 doesn't handle well: data wiring. V0's proxy routes work for simple cases but any non-trivial API shape requires going back and being very explicit. Prompt 2 (wiring to real data) required more back-and-forth than Prompt 1 (building the UI).

The annotation feature is underused. In V0 Max, you can click any element in the preview and leave an annotation. "Make this number bigger." "This progress bar should be red when below 20%." This is dramatically faster than re-prompting the whole component. Use it.

The Next.js 16 Breaking Change Nobody Warned Me About

This one cost an hour.

In Next.js 15+, route params are now a Promise. If you have a route like app/api/drops/[dropId]/route.ts, the params signature changed:

// Next.js 14 (old)
export async function GET(
  req: NextRequest,
  { params }: { params: { dropId: string } }
) {
  const { dropId } = params; // fine
}

// Next.js 16 (current)
export async function GET(
  req: NextRequest,
  { params }: { params: Promise<{ dropId: string }> }
) {
  const { dropId } = await params; // required
}

The error message when you get this wrong is:

Type 'typeof import("...route")' does not satisfy the constraint 
'RouteHandlerConfig<"/api/drops/[dropId]">'.

This error is not particularly clear about what's actually wrong. The fix is await params everywhere you destructure route segment params. I had three routes that needed fixing.

The Vercel × AWS Integration: Better Than Expected, With Caveats

The Vercel AWS Marketplace integration is genuinely slick. You click through a wizard in the Vercel dashboard and it:

Provisions an Aurora PostgreSQL cluster (or DynamoDB table)
Creates an IAM role with least-privilege policies
Sets up OIDC federation between Vercel and AWS
Populates your environment variables automatically

The result: your serverless functions authenticate to AWS databases using short-lived OIDC tokens with zero stored credentials. No Secrets Manager, no password rotation, no long-lived access keys.

The code is clean:

import { awsCredentialsProvider } from "@vercel/functions/oidc";
import { Signer } from "@aws-sdk/rds-signer";

const signer = new Signer({
  hostname: process.env.PGHOST!,
  port: Number(process.env.PGPORT ?? 5432),
  username: process.env.PGUSER!,
  region: process.env.AWS_REGION!,
  credentials: awsCredentialsProvider({
    roleArn: process.env.AWS_ROLE_ARN!,
    clientConfig: { region: process.env.AWS_REGION },
  }),
});

const pool = new Pool({
  host: process.env.PGHOST,
  password: () => signer.getAuthToken(), // fresh token per connection
  ssl: { rejectUnauthorized: false },
});

The caveats:

1. Environment variable prefix chaos. When you install two AWS integrations (we installed both Aurora and DynamoDB), the env var prefixes differ. Aurora uses no prefix (PGHOST, AWS_ROLE_ARN). DynamoDB, when installed second, gets a prefix that depends on what you name it during setup — ours ended up as DYB_ (DYB_AWS_ROLE_ARN, DYB_DYNAMODB_TABLE_NAME). This isn't documented prominently. Check your actual .env.local after running vercel env pull.

2. Development environment checkbox. When connecting integrations to your project, there's a checkbox for which environments (Production, Preview, Development) get the env vars. It's easy to miss Development. If vercel env pull returns only VERCEL_OIDC_TOKEN, this is why — go back to the integration settings and check Development.

3. Local OIDC auth depends on the IAM role trust policy. The VERCEL_OIDC_TOKEN that vercel env pull injects locally is a development token from a different issuer than the production token. Whether it works locally depends on whether the IAM role's trust policy includes the development issuer. Ours didn't initially, so npm run db:test failed locally even though production worked fine. The pragmatic fix: add dotenv to aurora.ts so the module works in both environments, and test primarily against the deployed URL.

4. The dotenv import must precede all AWS imports. In ES modules, static imports are hoisted and executed before runtime code — including config(). This means:

// WRONG: AWS SDK is imported before .env.local loads
import { awsCredentialsProvider } from "@vercel/functions/oidc";
import { config } from "dotenv";
config({ path: ".env.local" });

// CORRECT: dotenv first
import { config } from "dotenv";
config({ path: ".env.local" });
import { awsCredentialsProvider } from "@vercel/functions/oidc";

This caused a Value null at 'roleArn' error that took longer than it should have to diagnose.

Schema Migration Without a Migration Tool

With a 3-day deadline, there was no time to set up Prisma or Drizzle. The approach: a single /api/migrate route protected by a MIGRATE_SECRET env var. Hit it once after deploy and all tables are created:

export async function POST(req: NextRequest) {
  const { secret } = await req.json();
  if (secret !== process.env.MIGRATE_SECRET) {
    return NextResponse.json({ error: "unauthorized" }, { status: 401 });
  }
  await query(`CREATE TABLE IF NOT EXISTS brands (...)`);
  await query(`CREATE TABLE IF NOT EXISTS lots (...)`);
  // etc.
  return NextResponse.json({ ok: true });
}

This is not a production pattern. It's a hackathon pattern that works fine when your schema is stable and you control when migrations run. For a demo with a 3-day deadline, it's the right call.

The Self-Healing Demo Problem

Dutch-auction drops expire. A 3-hour drop is great for live demo urgency but terrible for a submitted hackathon project that judges might visit at 11pm three days later.

The fix: a /api/ensure-drops endpoint that checks how many live, unexpired drops exist and reseeds automatically if the count falls below 3:

export async function GET() {
  const countResult = await query<{ count: string }>(
    `SELECT COUNT(*) AS count FROM drops
     WHERE status = 'live' AND ends_at > NOW()`
  );
  const liveCount = parseInt(countResult[0].count, 10);
  if (liveCount >= 3) {
    return NextResponse.json({ seeded: false, liveDrops: liveCount });
  }
  await seedAllDrops(); // creates 6 new drops with fresh timers
  return NextResponse.json({ seeded: true, liveDrops: 6 });
}

The frontend calls this silently on every page load via useEffect. A Vercel cron job calls it daily as a backup. Judges always see a live marketplace regardless of when they visit.

The cron configuration in vercel.json (note: Hobby plan limits to daily frequency):

{
  "crons": [
    {
      "path": "/api/ensure-drops",
      "schedule": "0 0 * * *"
    }
  ]
}

What the Final Build Looks Like

After 3 days:

Homepage with 6 live drop cards, real-time decaying prices, countdown timers
Drop detail page with live price, claim form, activity feed, Dutch auction explainer
Brand analytics dashboard with recovery rate table and chart
Full dual-write claim endpoint (DynamoDB atomic decrement → Aurora transaction)
Self-healing seed system so the demo is always live
OIDC authentication with no stored passwords

The thing I'm most satisfied with is the claim handler. It does exactly one thing — decrement inventory atomically, record the transaction relationally — and it does it correctly under concurrent load. That's the core of the product.

The thing I'd do differently: start the database connectivity earlier. The OIDC auth quirks and env var prefix confusion cost nearly a day. If I'd run vercel env pull and confirmed the variables immediately after installation, the rest of the build would have been smoother.

Practical Tips If You're Building on This Stack

Use V0 Max for complex multi-page builds. The quality difference from Mini is significant. For simple components, Mini is fine.

Check vercel env pull output immediately after installing any integration. Note the exact variable names — they may not be what you expect.

Put dotenv at the top of any module that initialises AWS clients. Don't rely on the calling code to load it first.

Test your API routes against the deployed Vercel URL, not locally, when using OIDC auth. Local OIDC works if the role trust policy includes the dev issuer; production OIDC always works.

await params in all App Router route handlers. It's a breaking change in Next.js 15+. Grep for { params }: in your route files and add await before you deploy.

ClearLot was built for the H0: Hack the Zero Stack hackathon. Stack: Next.js 16, TypeScript, Tailwind, shadcn/ui, V0, Aurora PostgreSQL, DynamoDB, Vercel. Live at clearlot.vercel.app.

Finding the Root Cause of Production Incidents in Seconds with GitLab Orbit & AI

Arek H — Wed, 24 Jun 2026 08:03:06 +0000

It’s 2:00 AM. Your phone buzzes. Production is down, the checkout service is throwing 500 errors, and your team is scrambling.

You pull up the incident, and the real pain begins. Which recent merge request broke this? Was it the payment service? The quota logic? A pipeline configuration? You’re manually hopping between GitLab issues, file diffs, CI/CD logs, and deployment histories while revenue bleeds.

This is the hidden cost of production incidents: the hours of manual, forensic archaeology required before anyone even knows what to fix.

For the GitLab Transcend Hackathon, I wanted to solve this exact problem. I built the Incident Root Cause Flow—an open-source, AI-powered agent that natively traverses GitLab's Orbit knowledge graph to find the guilty commit in seconds.

Here is how it works, how it leverages graph traversal, and how you can install it in your own GitLab projects.

The Concept: Traversing the SDLC Graph

The flow is built entirely on the GitLab Duo Agent Platform and powered by GitLab Orbit.

Orbit is a knowledge graph that maps your code structure (definitions, references, call graphs) and connects it to your SDLC objects (issues, merge requests, pipelines, deployments). Because everything is linked, we can trace a failure backward.

When a new Incident is created, the agent wakes up and executes this precise traversal path:

Find Candidates: Queries the graph for all MRs merged recently.
Inspect Diffs: For each MR, it finds the changed files.
Map the Code: It extracts the specific functions/definitions that were altered.
Trace the Blast Radius: It follows the CALLS edge to find exactly which downstream functions rely on the changed code.
Cross-Reference CI/CD: It checks if the HAS_HEAD_PIPELINE edge indicates a failed test run before the code was merged.

The agent scores each MR based on this graph evidence and posts a beautifully formatted Markdown comment directly to the incident, complete with a confidence rating and the exact call-chain that broke.

Incident → Project → MergeRequest (failed pipeline?) → MergeRequestDiffFile → File → Definition ←[CALLS]← callers

Instead of digging blindly, the on-call engineer has a confidence-scored analysis and a direct link to the likely culprit within 30 seconds.

How to Install the Flow

Because this is a native GitLab Duo Flow, there are no external servers, webhooks, or Python scripts to host. It runs securely inside your GitLab environment.

Navigate to your GitLab project.
Go to AI → Flows (or search for the AI Catalog).
Click New flow.
Give it a name like Incident Root Cause Analyzer.
Grab the config.yaml from the open-source repository and paste it into the YAML configuration editor.
Click Save.

Note: The YAML dynamically injects your project ID using {{project_id}}, so it is completely portable out of the box.

How to Use It (Attaching the Trigger)

Once the flow is saved, you need to tell GitLab when to run it. We want this agent to fire automatically the moment a production issue is logged.

Still in the Flows interface, switch to the Managed tab.
Find your new flow and click Enable.
Under the Add triggers section, select Work item (Created).
Ensure your project is selected as the target.

Testing the Automation

To see it in action:

Go to Plan → Issues → New Issue.
Change the Type dropdown to Incident.
Give it a realistic title, like checkout-service returning 500s, and hit submit.

Wait about 30 seconds, refresh the page, and the agent will have posted its complete root cause analysis as a comment, isolating the exact MR and code definitions that caused the outage.

What's Next?

Mean Time to Resolution (MTTR) doesn't have to be bottlenecked by human context-switching. By combining LLM reasoning with strict, deterministic graph traversal via Orbit, we can eliminate the guesswork of incident triage.

You can check out the full source code, the demo application, and the prompt engineering in the GitLab repository here.

Happy hacking, and may your on-call shifts be quiet!

System Status: ONLINE – A Terminal-Inspired Portfolio for Backend Architect 🖥️⚡

Arek H — Fri, 30 Jan 2026 05:51:58 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hi, I'm Arkadiusz! 👋

I'm a Senior Backend Architect who has spent more time looking at terminal windows and Grafana dashboards than pretty UI layouts.

For the New Year, New You Portfolio Challenge, I wanted to break away from the standard "Hero Image + Bio" template. Instead, I asked myself: "What if my portfolio looked like the tools I use every day?"

The result is a High-Availability, resilient portfolio that visualizes my skills as "system resources" and invites visitors to interact via a CLI-style interface.

Portfolio

How I Built It

I built this project to be as lightweight and resilient as the backend systems I design.

The Stack

Frontend: React + Vite for blazing fast build times.
Styling: Zero UI Frameworks. I used pure CSS Variables (Design Tokens) and Flexbox/Grid. No Bootstrap, no Tailwind. Just clean, semantic CSS.
Hosting: Google Cloud Run. The app is containerized with Docker and served via Nginx. This allows it to scale down to zero (saving costs) and scale up instantly when traffic hits.

The AI Co-Pilot

I paired deeply with Google's Gemini throughout the process. It wasn't just about generating code; it was about rapid prototyping:

SVG Math: I used Gemini to calculate the control points for the Bezier curves in the "Blood Pressure" widget graphs.
CSS Glassmorphism: Fine-tuning the backdrop-filter and border transparency to get that perfect "Head-Up Display" look.

What I'm Most Proud Of

There are three features I'm particularly happy with:

1. The "Blood Pressure" Widget 💓

In the top right, instead of a static "Hire Me", I built a live "System Status" monitor. It simulates server load (or my caffeine levels ☕) with a randomized React state machine that transitions between Normal, Elevated, and High load, changing colors and graph shapes in real-time.

2. The Interactive Tech Stack 📚

The /stack page isn't just a list. It's a filtered matrix of my 29+ mastered technologies. I added a custom "Expertise" calculation that aggregates my years of experience across active filters.

3. CLI Contact Form ⌨️

The /contact page is styled like a terminal window (visitor@portfolio:~/contact).

Interactive Buttons: The Hire_Me() button in the nav isn't just a link—it passes a smart query parameter to pre-fill the form with "Project Inquiry".
Quick Actions: Buttons like initiate_consultation() run macros that auto-focus fields or open external scheduling tools.

Deployed with ❤️ on Google Cloud Run.