The person behind the work
I follow the problem
across technical boundaries.
I’m Necati Demir, a PhD computer scientist and technical leader with more than 20 years in software engineering and 12 years of formal leadership.
My work spans architecture, infrastructure, engineering delivery, data, and production AI because consequential technical problems rarely remain inside one boundary. I have held CXO-level responsibility and managed teams of up to 30 people.
A production failure may begin with architecture. A delivery problem may actually be an ownership problem. An AI problem may be an evaluation, permissions, data, or infrastructure problem.
I follow the problem until the company has a decision, an owner, and a path forward.
Following the problem across boundaries
As CTO at Datagran, I led engineering and introduced a new development and release cycle. Production bugs fell from approximately 300 to fewer than 10, and product NPS improved from negative scores to between 90 and 100. My leadership examples describe that work and a customer forecasting project.
Clients have often brought me in for a narrow implementation problem. My responsibility expanded when the work exposed problems in architecture, infrastructure, delivery, machine learning, or technical ownership.
I stay close enough to the work to test important assumptions and intervene directly where doing so removes a critical constraint. That involvement helps me understand the consequences of executive decisions while the engineering team retains ownership of its work.
That is the perspective I bring to fractional CTO work.
What I believe
- Architecture is a map of decisions and responsibility, not merely components.
- Delivery problems are often ownership problems before they are process problems.
- AI is not production-ready until its failures, evaluation, permissions, cost, and deletion paths are owned.
- Technical leadership should make the engineering team less dependent on one person.
- The business should keep producing while the system underneath it improves.
Selected work
These projects show how I work across models, applications, infrastructure, deployment, evaluation, and production constraints.
- Decision models
BranchOne
A System One decision model for choosing among supplied candidates using text and optional image input, with workflows for training, evaluation, and inference.
Technical judgmentMaking evaluation and choice quality part of decision-system design.
- Data infrastructure
StarRocks Docker Cluster
A six-node StarRocks environment with repeatable initialization, version-specific storage, configuration management, and smoke tests.
Technical judgmentMaking data infrastructure repeatable and checking its operational behavior.
- Model serving
Llama 3 Quantization and Serving
A workflow for quantizing Llama 3 to W8A8 and serving it through vLLM, with smoke tests and concurrent-request latency measurements.
Technical judgmentMaking model-serving tradeoffs measurable through quantization and concurrency testing.
- Local inference
Rust ONNX Chat
A Rust command-line application for running small language models locally through ONNX Runtime, with interactive and piped input.
Technical judgmentFollowing inference across model export, the runtime, tokenization, and the application boundary.
Building and writing
I write about software, AI, and technical leadership through the questions that come up in real work. What does a metric tell us? Who owns a decision? What happens when a prototype reaches production?
Start with my selected writing on technical ownership, architecture, delivery, and production AI.
Based in New Jersey
I work independently with companies where software is critical to customers, operations, or growth. You can find my work on GitHub or connect on LinkedIn.