Services
Project consulting in five practices.
Pick the system that is stuck. If the release around it is the stuck part, that is build automation beside the system, not a different firm. If two are stuck, say so — the usual order is to fix the record before adding a model, and an iOS app is its own project.
01Siebel CRM
Configuration, upgrades, workflow, and the integrations around Siebel. For internal IT groups that inherited an instance and do not have a bench of Siebel developers.
Read the practice
02.NET applications
Internal applications, integrations, and careful modernization. For firms whose operational software is a .NET system the current team did not write.
Read the practice
03iOS development
iOS project consulting for a defined app: a new build, a release that is stuck, or a codebase the current team did not write. The public example is Curio, an iPhone game Jon helped develop in 2012.
Read the practice
04AI consulting
Practical AI for small and boutique IT clients. Drafting, classification, and internal assistants that read from Siebel, a .NET application, or the documents the team already keeps.
Read the practice
05Build automation & IaC
Ansible, Terraform, and GitHub Actions or GitLab CI, scoped to a release that is still a manual checklist. Infrastructure as code and CI for a defined project. Not a DevOps agency and not a standing platform team.
Read the practiceHow to choose
Start from the system, not from a category.
Siebel is the book of record
The pain is inside Siebel, or in the integration that leaves it. Start withSiebel CRM.
An internal application is the business
Billing, staffing, cases, or the screen people actually live in. Start with.NET applications.
The deliverable is an iPhone or iPad app
A defined mobile release, including a codebase the current team did not write. Start withiOS development. This is project consulting. It is not a game studio.
The facts exist, the writing does not
A repeated draft or sort, on data you already store. Start withAI consulting. If the fields are wrong, fix those first.
The release is the toil
The environment cannot be rebuilt, or the deploy is still a checklist. Start withbuild automation & IaC. Ansible, Terraform, and GitHub Actions or GitLab CI, beside Siebel or .NET. Not a DevOps retainer.
Process
The same three steps, whichever practice it is.
Assess the constraint. Build the change. Support the handoff. Support here means the same person, through go-live — not a ticket portal.
01
Assess
Read the system and the constraint before writing a change. The output is a scope: what is in, what is out, and what done means for this project.
02
Build
Do the work — configuration, code, integration, or a narrow AI workflow against data you already keep. You see the change in the system, not only in a slide.
03
Support
Stay for the handoff and the questions that show up after go-live. This is project continuity with the same person. It is not a ticket queue, a monitoring contract, or overnight coverage.
If the system matters and the team is small, start with a conversation.
A paragraph on the system, the constraint, and the timing is enough. Jon reads these. There is no intake desk.