01
Development leadership.
Two decades leading the building of software, which is mostly the discipline of deciding what not to build and who has to live with it afterwards.
Samuel Hebeisen founded org.tech and operates it. This page is the background, the change in his thinking, and what he holds to.
The person who built it is the person you talk to.
He designed the platform, wrote most of it, deploys it, and answers the phone. That is an unusual thing to advertise, and it is the single most load-bearing fact about buying from a practice this size. What follows is written in the third person because a founder page written in the first person tends to become a pitch.
Twenty years of shipping, three of this.
BACKGROUND · TWENTY YEARS
Samuel Hebeisen has spent roughly twenty years in software development leadership, and the last three of them concentrated on AI implementation: building automation, deploying governed environments, and spending an unusual amount of time on the part most projects skip, which is who is accountable for what the system does.
He holds cloud solutions architect certifications at associate and professional level, and in 2026 completed the University of Waterloo's WatSpeed AI-CTO Certificate programme, a course written for the people who have to make AI decisions at an executive level rather than a technical one. Both matter here for the same reason: the platform is a cloud architecture problem wearing an AI hat.
Stated, not implied
Nothing embellished
No claim without a mechanism
02
Three years on AI.
Concentrated on implementation rather than experimentation: governed deployments, retrieval over an organization's own material, and the automation around it.
03
Cloud architecture.
Solutions architect certifications at associate and professional level. The controls this platform relies on are cloud identity and network controls, not application settings.
04
An executive programme.
The University of Waterloo's WatSpeed AI-CTO Certificate, completed in 2026. Its lasting effect shows up in the next section rather than in a credential line.
What he stopped doing.
THE TURN · WHAT CHANGED
Two habits had to go, and both were the habits of a good engineer. The first was carrying one technical pitch into every room, as though a CFO, a security owner and an operations lead were asking the same question in different accents. They are not, and the pitch that satisfies one of them tends to alarm another. The second was reflexively solving an implementation problem by becoming the implementer, which feels like service and quietly makes the company depend on one person being free.
| Situation | The earlier instinct | What he does now |
|---|---|---|
| Walking into a room with a decision-maker | One technical pitch, carried everywhere | Answer the question that room actually holds: risk for one, cost for another, throughput for a third |
| A build that missed the intent | Build it again himself | Improve the scaffold, the validator, the documentation or the support path first. Step in as builder when the issue belongs to the platform or crosses a security boundary |
| What the relationship rests on | The client trusts him | Trust the standard and its evidence. A relationship resting on one person is a ceiling, not a moat |
| Preparing for a hard meeting | Prepare the argument | Prepare the evidence, and separate what is measured from what is a working target before anyone else has to ask |
This is a description of a change in practice, not a personality claim. Its effect on the product is concrete: it is why judgment gets encoded into the validator and the factory rather than applied by hand, and why this site refuses to print a figure nobody measured.
The recommendation is not "trust Sam". It is: own the environment, inspect the evidence, and keep the exit open.The founder, on how to buy from a founder
What he holds to.
POSITIONS · SIX OF THEM
01
Ownership is the whole argument.
"Most private AI means they hold your data privately. Ours means you do." Every commercial and architectural decision in the company follows from that sentence, including the ones that cost us margin.
02
Policy belongs in the system.
"Your policies, applied in the system. Not a PDF, not a black box." A governance document that no mechanism enforces is a statement of intent, and an auditor can tell the difference.
03
Inference is not always the answer.
"Inference does not belong in a zero-error critical path. AI is sometimes the runtime, and sometimes it is the tool used to build the runtime." Most of what organizations actually use day to day never calls a model.
04
The standoff is the opportunity.
"The security owner carries the risk if they say yes. The operating owner carries the cost of saying no." Nothing moves until both of them can say yes to the same controlled capability, and building that thing is the work.
05
Keep the claim exact.
Exact claims beat broad ones. Name the region, the model, the retention posture and the tier, or say nothing. A working target stated as a result is the failure this industry makes most often, usually by accident.
06
Enablement before intervention.
Improve the environment others build in before taking over the build. It is slower the first time and it is the only version of this practice that survives its founder being busy.
Where the argument gets tested.
IN PERSON · TALKS AND WRITING
He runs the age:AI evenings, and speaks regularly.
age:AI is a paid AI awareness evening for regional decision-makers, run about twice a year. The seventh edition was held on 14 September 2026 during Waterloo Tech Week. Talks, formats and how to invite him are on the speaking page.
org.tech · Speaking→
The arguments, written down and dated.
Field notes on residency, the standoff between security and operations, and why the models run inside your own cloud. Written to be checked rather than shared.
org.tech · Pulse→
Our own deployment, open to look at.
The demo is the same product running for us, not a mock built for a sales call. It is the fastest way to judge whether the engineering matches the writing.
org.tech · Demo→
On authorship
Where a page or a post is an architecture argument, a technology evaluation or a piece of pricing analysis, it carries his name, because those are judgments a person makes and should be accountable for. Nothing on this site is attributed to a person who did not write it.
How to reach him.
CONTACT · NO QUEUE
There is no switchboard and no sales team, which means the reply you get is from the person who would do the work. The fastest route is the assessment call; the slowest is a form, and even that lands in one inbox.
- 01Book the strategic assessmentA bounded $2,500 engagement. The call is with him, and so is everything after it.→
- 02LinkedInWhere most of the regional conversations start, and where the event invitations go out.→
- 03Send a noteThe contact form, for a question that does not need a call yet. A reply from Sam, not a sequence.→
- 04Invite him to speakKeynote, executive briefing, panel or workshop, and the age:AI evenings.→
- 05Read the posture questionnaire firstThe questions he will ask your security owner, published so you can see them before the call.→
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
A bounded $2,500 engagement, run by the person who designed the platform, ending in a written plan you keep either way.