Web Apps, Logins and Databases

Most small-business sites eventually need to do something, not just show something. A contact form that quietly drops messages. A booking request that lands in a spreadsheet by hand. Members or clients who need their own page. A dashboard so you can see what came in this week. The usual answer is another plugin or another monthly app subscription, and each one adds weight, cost and a new place for things to break.

I build that functionality as small, owned pieces of code on Cloudflare, the same platform the site runs on. Remote-first from Fort Worth and across the DFW metro.

What I build

• Forms that reach you: contact, quote and booking forms with server-side checks, spam protection and email delivery, so a message is either delivered or the visitor is told it was not.
• Logins and members-only pages: pages and files only signed-in people can see, for clients, members or staff.
• Dashboards and admin pages: a private view of what came in, with the actions you need, such as approving or exporting.
• Small databases: Cloudflare KV for simple records and D1 (SQL) when the data has relationships and needs real queries.
• Connections to other services: email, calendars, payment links and the APIs your business already uses.

Built on this site first

The functionality on this site is the same kind of work, and you can try it:

• The contact form checks each message on the server, filters spam without a puzzle, and sends it by email; the page tells you whether it went through.
• The review system on the home page holds each new review until I approve it from an emailed link, then publishes it. Nothing appears unchecked.
• The free site audit fetches any public site, runs 44 checks on it and returns a grade in seconds.
• A connection point for AI assistants lets assistants that support the Model Context Protocol read this site’s services and contact options in a structured way.

Behind the scenes I also run a private operations console with a login, dashboards and scheduled jobs, built the same way.

How I work it

I start from what the app has to do and who uses it, then write a short spec you can check before any code: the screens, the data it keeps, who can see what, and what happens when something fails. Security is part of the design, not a pass at the end: input is checked on the server, secrets stay out of the code, and access is limited to the people who need it. That comes from the rest of my work, five years of production infrastructure and security engineering.

You get working software, the source in your repository, and a runbook. If you want me to keep it updated, the managed care plan covers that; if not, it is yours to run.

What I promise, and what I don’t

I promise an app that does what the spec says, that you own, and that is documented well enough for someone else to maintain. I will not promise a feature list I have not scoped, and if what you need is better served by an existing product you can simply subscribe to, I will tell you so. Tell me what the app has to do and I will come back the same day with a fit assessment and either a quote or a referral.