Line-of-business applications
Scheduling, intake, dispatch, inventory, invoicing — the internal software a company actually runs on, built around how the work is really done rather than how a product category thinks it should be.
Oklahoma City · Independent Software Engineering
One Person. One Paradigm Shift.
in Web Development
I design, build, secure and maintain software for Oklahoma City businesses — the whole job, by one engineer working with AI, at a pace that used to require an agency.
- One
- engineer, from the first conversation through years of maintenance
- Zero
- client-side frameworks between your customers and your content
- OKC
- where it is designed, deployed and supported — same time zone, same city
01 The thesis
Software has been getting heavier. Yours does not have to.
I am Pedro M. Dominguez. I build business software in Oklahoma City, and I build it deliberately small. Most of what makes modern web projects expensive is not the problem being solved — it is the machinery bolted around it: build pipelines, framework migrations, hundreds of transitive dependencies, and a team large enough to keep all of it standing.
Strip that away and something surprising happens. A single engineer with good tools and AI assistance can deliver, secure and maintain real systems on a timeline that used to require a firm. Not by cutting corners — by removing the parts that were never load-bearing.
This site is the argument and the evidence. It is a few hundred lines of TypeScript on the Deno runtime, standard library only, no framework, served straight from a single process. Read the source; it is the same way I build for clients.
- 01 Internet
- 02 Nginx
- 03 Deno
- 04 Your functions
02 What I build
Practical systems for businesses that run on them.
Systems that survive bad networks
Field tools that stay usable at the edge of coverage, capture work locally, and reconcile cleanly. The device is treated as authoritative; the server reconciles.
Security as architecture
Validation at the boundary, strict Content-Security-Policy, least-privilege processes, safe error handling. OWASP guidance shapes the design instead of arriving as a punch list after launch.
Deployment and stewardship
Ubuntu LTS, Nginx, systemd, backups you can verify. Software delivered as a running service on infrastructure you own, documented well enough that you are never captive.
03 Approach
Every engineering decision, translated into what it costs you or saves you.
-
Simple architecture
Software you can still change in year three. A system small enough to hold in your head is a system that can be fixed the day it breaks, by whoever is holding it.
-
Local-first design
Work continues when the connection does not. Trucks in rural Oklahoma, a shop with flaky wifi, an office during an outage — the application keeps taking input and reconciles later.
-
Minimal dependencies
A smaller attack surface and less debt. Every package you do not install is a supply chain you do not have to audit and an upgrade you never have to schedule.
-
Explicit permissions
The server can only do what it was granted. Deno starts with no access to your disk, network or environment; each capability is written down where it can be reviewed.
-
AI-augmented delivery
Agency-level pace with one phone number. Review, refactoring and test scaffolding move quickly — while the person who wrote your system is the person who answers the call.
-
Standards, not frameworks
Nothing to migrate off later. Requests, responses, URLs and forms are Web Platform primitives, so your software does not expire alongside a framework's release cycle.
04 The advantage
An agency has more people. That was only ever an advantage when software required more people.
No handoff loss
The person in your discovery meeting is the person writing the code and the person answering at 7pm when something looks wrong. Nothing is lost between an account manager, a designer, an offshore team and a maintenance contract.
No stack tax
An agency's estimate carries the weight of its standard stack — the build pipeline, the framework upgrade, the dependency audit. A small architecture removes that line item from the bid and from every year that follows.
Iteration at machine speed
AI-assisted development compresses the mechanical parts of the work: scaffolding, tests, refactors, review passes. Judgment stays human; typing stops being the bottleneck.
The result is not a smaller version of an agency engagement. It is a different shape: less surface area, fewer meetings, and a system you could hand to another engineer tomorrow without an archaeology budget.
05 Selected work
Software for the businesses that keep this city running.
Not demos. Systems that a shop, a distributor or a contractor depends on during business hours — each one small enough to explain in a paragraph and to maintain for years.
Route Ledger
Delivery logging for a regional distributor whose drivers lose signal every day.
The problem
Drivers covering rural routes outside the metro were recording deliveries on paper because the vendor app blanked out the moment cell coverage dropped. Proof of delivery arrived at the office a day late, disputed invoices took a week to settle, and the office manager re-keyed every ticket by hand.
What was built
A route application that runs entirely in the driver's browser and keeps working with the radio off. Stops, signatures and photos are captured locally and reconciled with the office the next time the truck has a usable connection.
Architecture
IndexedDB holds the day's route as the source of truth on the device. A service worker serves the application shell so a cold start needs no network at all. Completed stops queue as an append-only log and sync through a single Deno endpoint that validates every record and resolves conflicts by stop id and timestamp.
Why this way
Connectivity is the constraint, so the design starts there. Treating the device as authoritative and the server as a reconciler removes the entire class of failures where a spinner blocks a driver who is standing at a loading dock.
Shop Scheduler
Bay scheduling and customer messaging for an independent auto shop.
The problem
Three service bays were booked on a paper calendar at the counter. Double-bookings were routine, customers called constantly for status updates, and the shop was paying a monthly per-seat fee for a scheduling product that still could not answer 'is my car ready'.
What was built
A scheduling board sized for the counter monitor and a status page each customer reaches from a texted link. Writing a status on the board is what sends the update; there is no second system to keep in sync.
Architecture
Server-rendered HTML with progressive enhancement: the board is usable with JavaScript disabled, and a small script upgrades it to live updates over server-sent events. State is a single SQLite database file. Customer links are signed, expiring tokens that grant read access to exactly one work order.
Why this way
A repair shop needs the counter screen to be correct, fast and boring. Server-rendered pages with one enhancement layer meant no build pipeline, no client framework to upgrade every quarter, and a system the owner can back up by copying a file.
Permit Intake
Document intake and review queue for a specialty contractor.
The problem
Permit packets arrived as email attachments, lived in one estimator's inbox, and went missing whenever that estimator was on a jobsite. Nobody could say which packets were waiting on the city and which were waiting on the office.
What was built
An intake form and a review queue with an audit trail. Every packet has a state, an owner and a history, and the queue is the only place work is tracked.
Architecture
Uploads are size-capped and content-type checked at the edge, written outside the web root with generated names, and served back only through an authenticated handler — the filesystem is never addressable from a URL. Form input is validated with Zod at the boundary, and state transitions are explicit functions with no hidden effects.
Why this way
File upload is where small business applications get breached. Making uploads unreachable by path, non-executable by storage location and validated by schema removes the common failure modes rather than filtering for them after the fact.
Counter Menu
Self-hosted menu and ordering page for a family restaurant.
The problem
The restaurant's menu lived inside a hosted page builder that loaded slowly on phones, charged a monthly fee to change prices, and pushed customers toward a delivery marketplace that took a cut of every order.
What was built
A fast, static-first menu the owner edits directly, with call-ahead ordering that sends tickets straight to the kitchen printer.
Architecture
The menu is generated from one structured data file into static HTML at startup. No client-side framework, no third-party scripts, no fonts or trackers from other origins — which is also what makes the Content-Security-Policy strict enough to be meaningful.
Why this way
Most of a restaurant's traffic is a hungry person on a phone on mobile data. Shipping static HTML and a few kilobytes of CSS is not a compromise for that audience; it is the best possible experience, and it costs a few dollars a month to run.
06 Working together
Four steps, no discovery-phase invoice.
-
Sit down at your counter
Free
An hour watching how the work moves today — the paper, the whiteboard, the spreadsheet everyone quietly maintains. Most of the design is already there.
-
Smallest useful system
Week 1
A written proposal for the smallest thing that removes the biggest daily friction, with a fixed price and a date. Not a platform. The part that pays for itself first.
-
Build in the open
Weeks 2–5
Working software on a staging URL from the first week, updated continuously. You use it while it is being built, and course corrections happen while they are still cheap.
-
Deploy and hand over the keys
Launch
Deployed to infrastructure in your name, with documentation, backups and the source. Ongoing support is a choice you keep making, not a lock-in you signed.
07 Start here
Tell me what is slowing your business down.
The first conversation is free and it is with me — not a salesperson. Describe the part of your day that runs on paper, a whiteboard or a spreadsheet nobody trusts, and I will tell you honestly whether software is the answer.
- Email pedro.dfedro@gmail.com
- Code github.com/grenas405
- Based in Oklahoma City, Oklahoma