The questions worth asking first.
What gets built, how an engagement runs, and what you are actually agreeing to before anything is signed.
Scope & engagement
What gets built, how a project starts and is priced, and what the timeline and the stack actually look like.
What do you actually build?
Complete software products, end to end: scope, interface, frontend, backend, integrations, deployment and handover. AI and automation is where a lot of that work now sits, and infrastructure, security and low-level systems are the depth underneath it, which is why the hard parts do not turn into a second vendor halfway through. The test applied to the work is whether the system still runs six months after handover, not whether the demo lands.
Can you build a complete product, or only the hard parts?
A complete product: scope, interface, frontend, backend, integrations, deployment and handover, owned end to end. The reason the site talks about depth so much is that the hard parts are where most builds actually fail, not that the surface is somebody else's job. If you already have a team and only need the part that is blocking them, that works too, and the scope document says which shape applies.
Are you only an AI, infrastructure or security company?
No. Those are the depth, not the category. Product engineering is what is sold: the whole build, including the interface people operate. What is unusual is that when the product needs an agent boundary designed, a deployment path rebuilt, or a problem traced below the application layer, that does not become a second vendor and a second contract.
What can we look at before committing?
The process and the work product, both published in full. How an engagement runs is written down end to end, and the documents a client receives are published as samples: the scope format, the architecture memo, the risk and access checklists, the runbook. That gives a buying process something it can check before anything is signed, which is what a case study is usually being asked to do and rarely does. The in-house builds under Work carry the engineering range across a product surface, a data system and an operating system, and the writing under Learn shows the reasoning at length.
Can you work with international clients?
Yes. Remote-first and global, based in India, working asynchronously by default with a scheduled checkpoint in your hours. Contracts, invoicing and NDAs are handled in writing before work starts, and infrastructure runs in your accounts wherever your data has to live.
How does an engagement start?
A call or a written brief, then a scoping document. It states the problem as understood, what will be built, what will not, and what counts as done. Nothing is billed until that document is agreed. If scoping shows we are the wrong company for the job, that is what you get told.
How long does a project take?
Scope decides it, which is why scoping comes first. The scoping document sets the stages, and each stage ships something usable, so progress is inspectable rather than promised. A duration is committed against that scope, once the integrations, the constraints and the acceptance criteria are known. A number quoted before that is a guess, and it is the guess that becomes the missed date.
How does pricing work?
Fixed price against a fixed scope for defined builds. A monthly retainer where the work is ongoing and the scope moves. Hourly for work too small or too open-ended to scope up front: a review, a spike, a short piece of hands-on help. For a defined build the price follows the scoping document, because a price quoted before the scope is understood is a guess dressed as a quote.
What stack do you work in?
Picked per problem, not per preference. The builds behind the company are a multi-tenant content platform, a natural-language analytics system and a privilege-separated display manager, so the range runs from application code down to the operating system. If you already have a stack, the work happens inside it. A rewrite has to justify its cost like any other moving part.
The company
Who does the work, how it scales for a larger build, and how continuity, specialists, security and IP are handled.
Who actually does the work?
Engineers, directly. The person on the first call is the person who writes the architecture, ships the code, and hands the system over. One accountable owner: no account manager relaying messages, and nothing lost in translation between the person who understood the problem and the person who wrote the code. Where a piece of the build genuinely calls for a specialist, that person is named during scoping and works on that piece, with the same owner still accountable for the result.
Can you handle a large project?
Yes, and the mechanism is specific rather than a hope. For larger builds, engineers come on for that project: named during scoping, scoped to its requirements, and under the same NDA and access rules as everyone else. Not pulled from a standing bench, and not retained after. One person stays accountable for the architecture and the outcome throughout, so the work scales up without the coordination tax and the translation loss a standing team introduces.
Do other specialists ever work on a project?
Sometimes, and never quietly. There is no outsourcing, no agency handoff and no marketplace pass-through. When a build genuinely calls for a specialist, that person is named during scoping, approved by you before they start, and scoped to that part of the project under the same NDA and access rules as everyone else. One accountable owner stays responsible for the architecture, the integration and the result, so you always know who is doing what and who answers for it.
How do you handle security and IP?
Access is least-privilege and scoped to the work in hand. Credentials stay in your secret store, never in source and never in a chat thread. Security is the starting position, not a hardening pass bolted on at the end. You own the code and the IP produced under the engagement, and an NDA can be signed before any detail is discussed.
Procurement and delivery
The engagement rails: what a scope document contains, how an NDA and credentials are handled, what handover includes, and how the work sits alongside your own engineers.
What does a scoping document include?
The problem as understood, the constraints it has to work inside, what will be built and what will not, the sequence of stages, and what counts as done for each. It names the assumptions it depends on, because an assumption nobody wrote down is the thing that changes the number later. Nothing is billed until that document is agreed, and if the scoping work shows the wrong company is holding it, that is what the document says.
Can you sign an NDA?
Yes, before any detail is discussed. Send yours and it gets reviewed and signed, or ask and a mutual one is provided. Nothing about an engagement, a system, or a company is published, referenced in writing, or used as an example without written permission, and that holds whether or not an NDA exists.
How do you handle credentials and access?
Least privilege, scoped to the work in hand, and time-bounded where the platform supports it. Credentials stay in your secret store: never in source, never in a chat thread, never in a ticket. Access is requested per system rather than granted broadly at the start, and it is handed back at the end of the engagement. Infrastructure runs in your accounts throughout, so revoking access is something you can do without asking.
What does handover include?
Source in your repositories, infrastructure in your accounts, and the reasoning written down as the work happened rather than reconstructed at the end. That means architecture notes, the decisions and the alternatives that were rejected, runbooks for the things that need operating, and the known limitations. The test is whether an engineer who was not on the build can pick the system up without a handover negotiation.
Can you work alongside our internal engineering team?
Yes, and it is often the better shape. That can mean owning one component end to end while your team owns the rest, working inside your repositories and your review process, or taking the part of the stack your team has no bandwidth to reach into. The scoping document states which boundary applies, because an unclear boundary between two teams is the most reliable way to lose a month.
The operating system
What 0dyssey is, who it is for, what it is built on, and the state the work is actually in today.
Is 0dyssey open source, and what is the licence?
The layers it composes are existing free software and keep their own licences regardless of anything decided here. The licence for the parts written for this project has not been decided, so there is nothing to announce and nothing to imply. It gets stated here once it is chosen. A licence quoted today would be a position taken for a website rather than a decision made about the software.
Who is it for?
Developers, systems people, and organizations running their own infrastructure: the people who work close to the machine and would rather own the layer underneath than negotiate with it. The more useful half of that answer is who it is not for. This is not an attempt to make Linux friendly for people who do not want a terminal. That problem is solved, and other distributions solved it: a graphical Linux desktop is genuinely good now, and building a worse version of one would help nobody. The audience here already chose the terminal and wants the environment around it to stop costing days of assembly.
Do I need Linux experience?
The design intent is that the command line is always there and is never the only way in. Comfort with a terminal should make the system faster to work in, not be the price of getting into it. Treat that as a commitment to hold the project to rather than a feature to plan around: the surface that would make it true is designed and not built, and there is nothing today you could sit in front of and test the claim against.
Is this a reskin of an existing distribution?
No. Void Linux is the base, with the Linux kernel underneath it, runit as init, xbps for packages and i3 as the tiling window manager. Those are proven layers and rewriting them badly would be a waste of everyone's time. It is not a fork, it is a careful composition: each layer does its job and hands off cleanly to the next. What is being built for this project is everything above them, the tooling, the defaults and the working surface, and that is the part worth judging. Someone else's defaults with a theme on top would not be worth shipping.
What hardware will it need?
There is no answer to that yet, and any figure printed here would be invented rather than measured. Running well on modest and older machines is a design goal, and it follows from the same decisions as the rest of the design: what is absent cannot cost you anything. But a requirement is a measurement, nothing is stable enough to measure, and a number published now is a number a future build would be held to for no reason. The requirements get published when they have been measured, and not before.
When can I try it?
You cannot. There is no build: no ISO, no installer, no package mirror, no release channel, no version number and no early-access list to join. There is also no date, which means there is no date being kept quiet. The work is written up as it happens, and following that writing is the honest way to track real progress instead of a marketing countdown.
What happens to my existing setup?
Nothing, because there is nothing to install. When there is an image, the intent is that it behaves like any other Linux installation: ordinary partitioning, an ordinary boot loader, ordinary dual boot, and documentation for the common configurations rather than a special path only we understand. None of that is a promise to plan around until an image exists and has been tested on real machines. Nobody should be repartitioning a working machine for software with no build.
Not answered here?
The quickest route to a real answer is a conversation about the actual problem.