I'm Jeb Seibel. I architect and build AI and data systems. Usually I'm the only engineer on the project, from schema through deployment. But don't get me wrong, I know other amazing engineers so if we need one I know how to find what you need.
Twenty-five years of this: mission-critical systems at Cisco, Amelia AI, Dell, and Disney, and since 2024, independent client work. Most of what I take on is a system somebody depends on being right (verification platforms, trading systems, data pipelines), where the interesting problem isn't the happy path but everything around it.
Not all of it is code. Over twenty-five years I've been an architect, a development manager, a project manager, a team lead, and the person who wrote the documentation nobody else wanted to write. If what you need is someone to work out what should be built and write it down clearly, that's a real engagement too.
Who this isn't for
Worth saying early, so you can stop reading if it applies:
- You need a team. I'm one engineer. If the work needs five people shipping in parallel to hit a date, hire an agency. I'll say so on the first call rather than after you've paid for discovery.
- An off-the-shelf tool already solves it. A lot of problems that sound like custom software are a product you can buy this week. If yours is one of them, I'd rather tell you than build you a worse version of it.
- The work is mostly prompt engineering. Most of what I build isn't the model. If your problem genuinely is "make this prompt better," that's a smaller engagement than the ones described here.
- You need someone in leadership meetings. Owning a technology org is a full-time job. The closest I offer is fractional technical leadership, which is a different and narrower thing.
You work with me directly. There's no account manager, no team behind the scenes, and no handoff between whoever scoped the project and whoever builds it.
I worked with Mr. Seibel on an AI project and he delivered on time and on budget. He was professional and knowledgeable throughout.
[Jason Westigard](https://www.linkedin.com/in/jason-westigard/), Chief Product & Technical Officer, Trax Technologies
AI Strategy
Decide what to build, and what it will cost you to live with.
Most AI advice stops at what's possible. The useful question is what happens after it ships: what it costs per document, what breaks when a vendor deprecates a model, and whether you can explain to a customer how a number was produced.
- Where AI actually fits. An honest read on which parts of your product benefit from a model and which are better served by ordinary software. Most systems need less AI than the pitch suggests, applied more carefully.
- Build vs. buy vs. wait. Evaluated against your team, your budget, and your timeline. Not against what's fashionable this quarter.
- Vendor risk. Hard-wiring to one AI provider inherits their pricing, availability, and deprecation schedule as your business risk. That's a survivable choice, but it should be a choice. I'll tell you what it costs to stay portable and let you decide.
- Architecture review. A read on a plan, a codebase, or a vendor proposal already on your desk, from someone with no stake in the outcome.
- AI you can defend. If your output gets audited, disputed, or sold to someone who'll scrutinize it, "the model read it off the PDF" isn't an answer. Designing for traceability is a decision made early or not at all.
Usually two to four weeks, ending in a written recommendation and a working session with your team.
Implementation
Architecture through deployment, built by the person who designed it.
This is the core of the practice, and typically I'm the only engineer on it: backend, frontend, data pipeline, deployment.
- Document and data extraction. Pulling structured data out of whatever your sources actually emit (PDFs, scans, CSVs, emails, screenshots), with the extraction step itself logged and reviewable, so any value can be traced back to the document it came from.
- Multi-provider AI integration. Model routing across providers with configured fallback, per-request cost metering, and prompts versioned in the database rather than hardcoded, so extraction behavior can be corrected without a deployment, and a price change at one vendor is a config change rather than a rewrite.
- Data pipelines and platforms. Ingestion, storage, and scheduled retrieval built for the access pattern you'll actually have, holding up under real volume.
- Systems that run unattended. Software that operates without a person watching, where a dropped connection or a bad upstream value is an expected state with a defined response rather than an exception someone escalates.
- Full-stack delivery. Java and Spring Boot, React and TypeScript, MySQL and Postgres, schema-as-code migrations, contract tests on the endpoints that matter. Also Flutter, when the surface is mobile.
- Hosting I can help with hosting if you need it; yours or mine.
Delivered incrementally against a plan agreed up front, with running software you can see and use throughout. Not one large reveal at the end.
Documentation and Delivery
The work that isn't code, from someone who has done the code.
Plenty of projects don't fail on engineering. They fail because nobody wrote down what was being built, or because there was no one to sequence the work and keep it honest. I've held those roles, and they're available on their own.
- Technical documentation. Architecture docs, runbooks, API references, and the handover material that decides whether your team can actually own a system after it ships. Written by someone who can read the codebase rather than interview around it.
- Specifications. Turning a rough idea into something engineers can build and stakeholders can agree on: the document that surfaces the disagreement before it becomes a rewrite.
- Project management. Planning, sequencing, and running delivery on technical work, including Scrum where that's how your team already operates.
- Product management. Deciding what to build and in what order, with enough technical grounding to know what each choice costs.
Useful when you have engineers but no one to point them, or a system that works but nobody outside its author understands.
Ongoing Support
Stay supported after launch.
- Maintenance and iteration. Fixes, refinements, and the next round of features, without restarting a hiring process every time something needs attention.
- Monitoring what drifts. AI systems don't fail cleanly. Models get deprecated, providers reprice, document formats change upstream, and extraction quality degrades quietly. Watching cost, latency, and output quality is ongoing work, not a launch task.
- Handover that sticks. Documentation and working sessions to get your engineers genuinely owning what was built. The goal is to make my continued involvement optional.
- Fractional technical leadership. Architecture review, code review, and technical direction for teams without a senior engineer in-house.
Usually a set number of days per month, arranged around what you actually need.
How engagements work
Start with a free call. Tell me what you're working on. No charge, no obligation, and if it isn't a fit I'll say so and point you somewhere better.
Then paid discovery, usually. For anything substantial, the first engagement is a short scoped block (typically two to four weeks) that produces a concrete technical plan. You keep the plan whether or not the work continues.
Then pick the shape that fits:
- Fixed-scope projects: a defined deliverable, agreed price and timeline. Best when the requirements are clear and the endpoint is understood.
- Retainers: a set number of days per month for ongoing work, support, or technical leadership. Best when the work is continuous or the roadmap is still moving.
- Advisory: smaller blocks for architecture review, second opinions, or specific technical questions.
Rates, minimums, and what drives a price up or down are on the pricing page.
How the work runs. Direct access to the engineer doing the work. Regular check-ins, running software early, and straight answers about what is and isn't going well, including when an estimate was wrong.
What you keep. All code, documentation, and infrastructure is yours, delivered in your repositories and your accounts. No proprietary platform to stay locked into and no dependency on my continued involvement.
What I'll tell you up front. If your project doesn't need what I do, you'll hear it on the first call rather than after you've paid for discovery. The specifics are at the top of this page.
Get in touch
Tell me what you're working on. If it's a fit, I'll say so, and if it isn't, I'll tell you that too, and point you somewhere better.