Cebras · Co-Founder & CTO · Founding engineer
Building a product from the ground up
As Cebras’s sole founding engineer, I’ve taken the technical product from its earliest stages to a working platform—shaping the experience, designing the architecture, implementing the frontend and backend, and handling infrastructure and deployment.
That means moving continuously between product thinking, design and engineering, while keeping the whole system working as the company and its requirements evolve.
The product
Cebras is an assessment and guidance platform designed to help people better understand their strengths, interests and possible directions. The experience brings together onboarding, assessments, evaluation, personalized reports and the workflows that make those services available to users.
Developing this isn't simply a question of building individual screens. Each part has to fit into a coherent product: people need to understand what to do, assessment logic has to be implemented consistently, access and payments have to work, and the platform has to be maintainable as new features are introduced.
My scope
End-to-end technical ownership
In the early development of Cebras, there wasn't a separate engineering team to hand work between. I was responsible for connecting the decisions and doing the implementation myself, from understanding a product requirement to making the resulting feature available to users.
- 01
Shape the product
Translate the founding team's priorities and specialists' assessment requirements into product flows, usable interfaces and a realistic engineering plan.
Product decisions · UX & design - 02
Design & build the system
Make architecture and data-model decisions, then implement and connect the frontend, APIs, backend, databases and integrations myself.
Architecture · Full-stack implementation - 03
Ship & keep it running
Manage hosting, deployment and production issues while extending the product for new journeys and changing requirements.
Infrastructure · Delivery · Iteration
The central challenge
Being responsible for the whole system
The difficult part of this work is the breadth of responsibility. A product decision might change the data model; a new assessment flow might affect the interface, backend and reports; a change to payments can alter how users receive access. When you're the only engineer, you have to see those dependencies, make the trade-offs and implement the changes across every affected layer.
I also have to decide when to move quickly and when an architectural decision needs more care. Building something that works today is only one part of the job: I need to be able to understand it, maintain it and extend it when the next requirement arrives. There is no separate team taking over the infrastructure, integration work or technical follow-through.
Much of that work happens between disciplines. Assessment content and scientific validation depend on subject-matter experts; product priorities involve the founding team. My role is to connect those requirements with the design and implementation decisions that make the platform work as one product.
A concrete engineering example
How one feature crosses multiple layers
A self-service assessment journey illustrates why this responsibility matters. The user-facing flow needs clear onboarding and checkout screens, but it also requires backend payment confirmation, access rules, persisted journey progress, assessment evaluation and reports. Those aren't isolated features; they have to agree on what a user is allowed to do and what state their journey is in.
I designed and implemented the software connecting those pieces. For example, the backend grants access after payment confirmation rather than relying on the browser returning from checkout. That's one small decision within a much larger challenge: owning how the entire experience is designed, implemented and operated.
What I've learned
Building Cebras has pushed me beyond thinking about the correctness of individual components. I've had to learn how to make decisions for a complete product, balance speed against long-term maintainability and connect technical implementation with the people defining the problem.
For me, the most significant part of this project isn't a particular framework or feature. It's having responsibility for the engineering of an evolving product—from first design decisions to the software that actually runs.