Work samples

A career in data, controls and fixing operations. Aimed at software for the last year.

Everything on this page I designed and built, and I still run most of it. Customers paying, cards getting charged, and a system that wakes me up when something breaks. Usually before anyone notices.

01 · The work

Four things I built, and why they're here.

Software is the last thing I reach for. Most problems get fixed with something you already own, badly set up. But every so often the tool you need doesn't exist at your size, and that's usually the point where you get handed a quote from somebody else.

A subscription business, end to end

SolveWise

Live

An AI math tutor sold by monthly subscription at solvewise.org. Not a demo. A product with customers, card payments and a support inbox.

  • Money actually moves through it. Trials, upgrades, cancellations and refunds, all handled without me touching anything. The card at signup doubles as verified parental consent, checked on the server where it can't be faked.
  • Every hour it signs itself up as a new parent on the live site, adds a child, reads the billing page, then tidies up after itself. If something's broken I hear about it before a customer does.
  • The expensive AI models get tested against the cheap ones, and the cheap one wins wherever it can. That's a margin decision, and I run it the way I'd run yours.
  • When it can't give a reliable answer it says so instead of guessing. Confidently wrong is the one thing I won't ship.

If you need software that takes money and isn't allowed to break, I've built one and I run it every day.

Client delivery

Client sites platform

Live

One system that publishes every client's website from their own record. No separate project per client, no files shuffled between folders.

  • First client is a mortgage broker, live on his own domain.
  • Intake goes out as a link and the answers land straight in the system. Nobody emails a form back and forth, nobody retypes anything.
  • Fix something once and every site on it gets the fix.

I build things that get reused, not one-offs that quietly rot.

Reporting

BudgetWise

In development

Variance reporting that follows a line from the money spent, to what it was meant to do, to what it actually did, to the next decision.

  • Drills from a department total all the way down to the work order or the paid bill.
  • Warns you before a department runs over and suggests where the money could come from. The department head still has to say yes.
  • Runs overnight, so Monday's number is Monday's number.

I build the reporting that tells you whether a change worked, including when it didn't.

Decision models

Working models, not spreadsheets

Live

Models built for specific decisions, where you move the inputs and watch the answer change: capacity and cost per unit, infrastructure economics across suppliers, and sales capacity against revenue by source.

  • Every number shows the formula behind it and what it's being measured against.
  • Move an input and the whole thing recalculates, so you find out which assumption your case was actually resting on.
  • Lives in a browser and gets shared by a link. Nobody has to own the right version of a file.

The analysis is something you can push on yourself, not a slide you have to take my word for.

02 · How it's built

The part you can't rent.

The stack itself is for rent. Anyone can have it, and a year of hard work got me fluent on it. What it's pointed at took longer. Budgets that had to survive an audit, controls that caught a problem before a customer did, and the habit of reopening a process everyone else had already signed off on. Software built that way tests itself, tells on itself, and doesn't need rebuilding every time your business moves. Most software gets built once and defended from then on.

It does the job it was built for

Before anything gets built we agree on what fixed looks like and how we'd know. After it ships we go and check. Software that matches the specification perfectly and leaves the problem exactly where it was is the most common way this goes wrong.

Tested the way you'd use it

Every build gets checked end to end, the way a customer would actually use it. And the test has to fail when the thing is broken, otherwise it isn't a test, it's decoration.

Loud when it breaks

Nothing degrades quietly. A system that hides a problem is worse than one that falls over, because the first you hear about it is from a customer who already left.

Built to be changed

Your business will move and the software has to move with it. Changes add before they take away, so backing one out still leaves you working, and the next change doesn't mean paying for the whole thing twice.

Built on Next.js · Supabase · Stripe · Vercel · Cloudflare · Anthropic API · Playwright · Sentry · PostHog · Resend

Same approach whatever it's pointed at.

Including whatever you bring me.
03 · Contact

So what's the one keeping you up?

Name the problem you'd fix first. The one that keeps coming back, or the one you've already paid somebody to fix once. I'll look at it and tell you straight whether I can help.

Everything on this page is something I can walk you through. The decision, the trade-off, and the parts I'd do differently now.

Emailtarak@wisebusinesssystems.com
Phone(760) 415-4492
LinkedInlinkedin.com/in/tarakp