What we've built, and what it's for

Four systems we designed and built end to end. Each one below covers what it does, how it's put together, and the kind of business it fits. The interface captures come from the software itself, running on demo data.

Sales CRM with an agent layer

A pipeline that tells you who to call, instead of a list you have to read

Most CRMs solve storage and call it a day. The owner still has to open the thing, read everything, and work out what matters. This one inverts that. An automated layer reads the pipeline continuously and escalates only the conversations that are genuinely time-sensitive, with the reason attached and a suggested next step, so the default state is a short list of decisions rather than a long list of records.

A CRM dashboard listing open escalations, hot leads, tasks due and follow-ups, with a panel of conversations flagged for a callback and two pipeline value dials.
Daily view. Interface shown running on demo data

How it's put together

  • One database as the source of truth, not a spreadsheet export
  • A read layer that can be pointed at demo data or the operational database
  • An automation pass that scores and escalates, writing its reasoning to the record
  • Every outbound action queued for human approval before it leaves

Built for

  • Sales teams whose follow-up depends on somebody's memory
  • Owners who want the exceptions, not another report
  • Businesses where a slow callback loses the deal
  • Any pipeline living across a spreadsheet and an inbox

Stack

  • Next.js
  • React
  • Supabase
  • Cloudflare
Membership & venue operations console

Applications, members, and room bookings that stop colliding with each other

One console covering the whole operational loop for a membership organization: reviewing applicants, holding member records and segments, and booking the room. The booking side is the interesting part. It checks the calendar for conflicts and for setup and cleanup buffers before a hold is confirmed, so two events cannot quietly land on the same evening and nobody discovers it on the day.

A venue booking console showing revenue for the month, pending approvals, today's events with setup and cleanup windows, and an alerts panel flagging a date conflict between two bookings.
Booking overview with conflict alerts. Interface shown running on demo data

How it's put together

  • Applications, members, segments and bookings in one schema
  • Conflict and buffer checks run before a hold is confirmed, not after
  • Decisions write an auditable record instead of living in a sent folder
  • Reporting reads the operational database directly, so there is no second version of the numbers

Built for

  • Membership organizations reviewing applicants on a rolling basis
  • Venue and room booking where a double booking costs real money
  • Teams running a recurring event calendar by hand
  • Anyone whose approvals currently happen over email

Stack

  • Next.js
  • React
  • Supabase
  • Cloudflare
Automated reminders & intake

A reminder engine that replaces the spreadsheet chase

Intake forms feed one database instead of four inboxes. From there the system schedules text message reminders at the right point in each record's life, tracks what was sent and what came back, and posts updates to the team's project board so nothing depends on somebody remembering to check. This one has no dashboard to show off, because the whole point is that it runs without anyone opening it.

How it's put together

  • Form submissions normalize into a single record per person
  • Reminders claim their slot atomically, so two workers cannot send the same message twice
  • Consent and opt-out handling built in from the start, not bolted on
  • Hard ceilings on how much can ever send in one run, plus a kill switch that does not need a redeploy
  • Delivery and replies logged against the record

Built for

  • Renewal and expiry deadlines: policies, contracts, memberships, licences
  • Appointment and service reminders that reduce no-shows
  • Any team tracking recurring dates in a shared spreadsheet
  • Businesses whose follow-up quietly depends on one person's memory

Stack

  • Supabase
  • Telnyx SMS
  • Monday.com
  • Jotform
Website & events platform

A site where the calendar and the event listings maintain themselves

A public website with the event calendar wired directly into it, so listings stop being maintained by hand in two places. Events publish once and appear everywhere. A speaker submission form lets people put themselves forward without starting an email thread, and their details land somewhere structured instead of in an inbox.

How it's put together

  • One event record drives the site, the calendar and the listing
  • Submissions write to a structured store, not an inbox
  • Runs on edge infrastructure, so pages are fast without a caching bolt-on

Built for

  • Organizations publishing a recurring event calendar
  • Conferences and groups taking speaker or vendor submissions
  • Anyone maintaining the same event details in three places

Stack

  • Cloudflare Workers
  • Next.js

Different businesses, same underlying parts: a clean data layer, automation that respects the rules, and a view an owner will open. That's why this transfers. If your problem rhymes with one of these, most of the thinking is already done.

Think one of these is close to your problem?

Bring it to a discovery call and we'll work out how much of it transfers. It's a real conversation, not a pitch.

  • About 30 minutes, no cost, no obligation
  • We walk through your current tools and where the work piles up
  • You leave with my honest read, including if that read is "don't spend money on this yet"

Prefer email? support@veris-ai.com. I answer my own inbox.