About BishopTech
Hi, I'm Matthew.
I'm a father, a full-time coder, and the person behind BishopTech. I build the websites, software, automations, and technical systems that help a good idea become a dependable operation.
When the issue is vague, the stack is tangled, or the next step is hiding behind twelve tabs and one nervous spreadsheet, I help turn the situation into a scope people can actually act on.
5+ years
web development
4 years
building with AI
20+
websites launched
Hundreds
workflows and automations
The short version
I've been building for the web for more than five years and working hands-on with AI for the last four. In that time, I've launched more than twenty websites and built hundreds of workflows and automations that move information, decisions, and follow-up from one place to the next.
The interesting part is rarely the shiny tool. It is the handoff between the tool and the real work: the form that needs to create the right record, the website that needs to explain the offer, the agent that needs a boundary, or the deployment that needs an owner after launch.
That is the lane BishopTech occupies. I can come in at the idea stage, inherit the repo nobody wants to touch, or help make a working system less dependent on luck and tribal knowledge.
The long game
2026's version of milking the cows.
I'm also a father to Camden and Kylan. They already have a few iOS games in progress, which means the family roadmap includes a surprising amount of SwiftUI, level design, and very serious arguments about what makes a good boss fight.
Eventually, I want them to work their way into BishopTech as iOS game developers. I built this company to become a technical foundation they can grow into as adults while AI and the rest of the industry keep changing underneath us.
It is the 2026 version of “milking the cows”: build something useful, take care of it, learn the new machinery, and leave the next generation a working operation they can improve instead of a barn full of mysterious switches.
How I work
Bring me the issue. We'll define the outcome, then make the system behave.
A technical problem does not need to become a technical personality test. I keep the scope connected to the result you want: launch the thing, recover the workflow, make the handoff clear, or stop paying for a system that still needs babysitting.
Name the problem
We start with what is actually stuck, expensive, fragile, or unclear—not whichever tool is having the loudest week.
Define the outcome
A useful scope says what should work, who it should help, and what done looks like before the build starts.
Build the missing bridge
I can repair the current system, launch the next version, or connect the pieces that have been pretending not to know each other.
Leave a map
You keep the repo, accounts, assets, and documentation. The system should be understandable after the launch adrenaline wears off.
Let's make something real