1. format
  2. lint
  3. typecheck
  4. architecture
  5. self-proof
  6. tests
  7. coverage
  8. e2e
  9. duplication
  10. security
main · greenwall 10/10sample

Wesley DeitchFront-End & Design EngineerWellsville, PARemote (ET)

Work 03

Strevian

ChurchVue

A church software platform for acapella churches of Christ. I designed and built its front ends: a church admin app, a 10-screen mobile member app and a 13-game Bible-learning app.

03 · Strevianprivate, described

Admin.Member.Games.

1 admin app · 10-screen member app · 13-game Bible-learning app

Role
Founder & Principal Engineer; I designed and built the front ends
Years
Jul 2026 to present
Lane
design + build
Tools
  • TypeScript
  • tRPC
  • Postgres

Proof

Every figure with what it measures, where it came from and when.

None of them is a headline on its own.

  • 3front ends: a church admin app, a mobile member app and a Bible-learning appChurchVue, private, described here · Jul 2026 to present
  • 10screens in the mobile member appChurchVue member app · Jul 2026 to present
  • 13games in the Bible-learning appChurchVue Bible-learning app · Jul 2026 to present

The work

Strevian

Jul 2026 to present

ChurchVue is a church software platform for acapella churches of Christ, built through my own company, Strevian. I designed and built its front ends on a TypeScript, tRPC and Postgres foundation with per-church data isolation and audit logging.

There is no public link yet, so this page describes the work rather than showing product screens.

Three front ends

  • A church admin app
  • A 10-screen mobile member app
  • A 13-game Bible-learning app

All three sit on the same foundation: TypeScript, tRPC and Postgres, with per-church data isolation and audit logging underneath every screen.

Its own design system

I kept ChurchVue on its own design system rather than the shared library, to keep each product's identity distinct. The three systems are on the design systems page.

Caught, not hoped

In one bootstrap the harness caught six defects in the agent's own code, and independent verifier agents found a tenancy hole that would have let any module read every church's data. It was fixed structurally before merge, with permanent attack fixtures, so the hole can never open quietly again.

I want holes found, not reassurance.

My line, and the reason verifier agents run at all
Tenancy hole diagramOne module and three churches, with an attack fixture at the wall between them. Tripping the hole lets the module read every church and the fixture turns red. The structural fix scopes the module to its own church and the fixture stays as a green permanent guard.ModuleChurch AChurch BChurch Cattack fixture · armed

fixture · cross-tenant read · armed · waiting

One module, three churches, an attack fixture at the wall between them. Trip the hole to watch the fixture fire; close it to watch the fixture stay.

The mechanism behind that catch is the engineering standard: twenty rules, eighty-two automated checks and a ten-stage merge gate, with me as the only manual gate.

Write to me

What do you need built?

It lands in my inbox and I reply by email. No list, no forwarding, no bot.

The role or the engagement, and what a good outcome looks like.

Nothing sent yet.

or write to deitchwesley@gmail.com