Tiknix Help Center
Help

How Tiknix works

You describe what you want built; agents build it into a real application with a database, a web server and a place to run. This is the short version of how the pieces fit together.
Stuck on something?

Send us a message and a person will read it. Tell us what you were doing and what happened instead — that is usually enough to sort it out in one reply.

Building something

1. A project

Everything you build lives in a project. It is a real application with its own database and its own address — not a sandbox you later have to port out of.

Projects →
2. Builder

Describe a change in plain language. It is broken into a plan you can read and approve, then built, and you can watch it happen. Small and specific beats large and vague — "add a stop button to the arrangement panel", not "improve the UI".

Ask an admin to enable this
3. Data

Pipelines move and shape data on a schedule — imports, syncs, scheduled jobs. Each step is visible and re-runnable, so when something breaks you can see which step it was.

Ask an admin to enable this
4. Deploy

Put it live — on a domain of yours, or on infrastructure of yours. Build with our system, deploy to yours.

Ask an admin to enable this

Working with other people

Teams

Share a project with people you work with. A team controls who can see and run what.

Teams →
Communications

Conversations tied to your work, in one inbox. Replies to a thread continue it rather than starting a new one.

Communications →
Invitations

Sign-ups are closed, so an invitation is the only way someone new gets an account. Each one is tied to a single email address.

Enabled per member by an admin

Questions people actually ask

Make a project. Nothing else in the system does anything until there is one to act on — the Builder, Data and Deploy all work on a project, which is why they show New Project until you have one. Then describe one small, real thing you want it to do and let the Builder do it end to end. A working small thing beats a plan.

Some capabilities are switched on per person by an administrator rather than being on for everyone — Builder, Data, Deploy, the Store, the Architecture Explorer, API/MCP access and Invitations. If one is not enabled for you it is hidden rather than shown-and-refused, because a link that always fails is a worse error message than no link.
Ask an administrator to enable what you need.

Lower numbers have more access.
  • Root (1) — full system access
  • Admin (50) — administrative access
  • Member (100) — a normal account
  • Guest (101) — not signed in
Level is separate from the per-person switches above: being a Member says what you are, the switches say what you have been given.

Both live on your profile. The password section is optional — you can change your display name without touching it. Your display name is what other people see, including in invitation emails; leave it blank and it falls back to your name, then your username.
Locked out instead? Use Forgot password on the sign-in page.

Nothing is silently lost — every task keeps its plan and its log, so you can read what it decided and where it stopped. The usual fix is a smaller, more specific request: name the file, page or behaviour you mean. If it looks like the system misbehaved rather than the instruction being unclear, tell us and include the task.
Didn't answer it?

A person reads every message that comes through here.

Message support