We Use Tixio to Build Tixio: How 72 People Run Everything in One Workspace

We build Tixio inside Tixio. Not as a marketing line, as the actual operating condition. There is no internal Slack, no separate Notion, no second project tool that the team quietly prefers. If something is broken in Tixio, we feel it before you do, usually on a Monday morning, usually in front of everyone.

This post is the honest version of what that looks like. Real numbers pulled from Soly, the workspace our team actually works in, on the day this was written, and what each team does inside it.

The numbers inside Soly right now

Soly is our shared workspace, the one the whole group works in every day. These are live counts pulled from it, not a demo environment and not a rounded up marketing figure.

• 72 people in one Soly workspace, spread across the companies in our group.
• 204 projects running at once.
• 14,730 tasks and 2,368 subtasks, so roughly 17,000 work items live in the system.
• 110 automations doing the repetitive parts nobody wants to own.
• 363 wiki pages across 63 folders.
• 89 chat channels.
• 87 boards used as daily start pages.
• 41 people on the HR module, every seat occupied.
• 17 seats on CRM, 16 in use.

None of that was built for a screenshot. It accumulated because this is where the work happens.

Why we ended up dogfooding this hard

The uncomfortable truth is that we did not start out disciplined about it. Early on we used Tixio for some things and other tools for the rest, the way most companies do. It felt reasonable. It was also the fastest way to never find our own bugs.

The turning point was a specific realisation. We were building a product whose entire promise is that you should not need seven tools, while running the company on seven tools. That is not a strategy problem, it is a credibility problem. So we moved everything in and set one rule.

If we need something Tixio cannot do, we either build it or we change how we work. We do not go buy a second tool and pretend the problem is solved.

That rule has been uncomfortable more than once. It has also been the single most useful product input we have.

What using it daily catches that testing does not

A test suite checks whether a feature works. Daily use checks whether a feature is worth using. Those are different questions and only one of them gets answered by QA.

The pattern of what dogfooding surfaces is remarkably consistent, and it is almost never dramatic.

• Friction that only appears at volume. A feature that is pleasant with 12 tasks becomes tiring at 900. You do not find that in a test environment, you find it in month four when someone quietly stops using the view you were proud of.
• The step nobody mentions in feedback. Customers report the bug that blocks them. They do not report the extra click they do forty times a day, because they have stopped noticing it. We notice it, because we are also doing it forty times a day.
• Defaults that are wrong for real teams. Almost every default we have changed was changed because our own team kept overriding it. If your own people configure around a default, the default is wrong.
• Features that sound good and get used twice. Being your own customer makes it hard to lie to yourself about adoption. The usage data for our own workspace sits right next to the roadmap.

The uncomfortable side of this is that it also makes us defensive about the things we personally use. A team that lives in its own product can mistake its own habits for universal ones. We try to correct for it by weighting customer interviews above internal opinion when the two disagree, and we do not always get that balance right.

Three things we got wrong along the way

Since this post is meant to be useful rather than flattering, here are the mistakes worth stealing from us.

• We created too many channels. 89 channels is honestly more than we need. Channels are cheap to create and expensive to maintain, and every dead one is a place a decision can go to hide. If we started again we would create channels reluctantly and archive them aggressively.
• We treated the wiki as a place to put things rather than a place to find things. For about a year we wrote plenty and organised nothing. The fix was not better software, it was assigning owners to sections and deleting monthly. A wiki without a gardener becomes an archive.
• We moved chat too early. Chat is a habit, not a system. Moving it before projects and documentation were settled meant people were learning a new tool while also having nowhere useful to point conversations. Move it last.

How each team uses it

Product and engineering

Every feature starts as a wiki page before it becomes a task. The PRD lives in Tixio Wiki, and the tasks that implement it live in a project that links back to it. That link matters more than it sounds. When an engineer asks why a field behaves a certain way six months later, the answer is one click from the ticket rather than a question in chat that costs two people twenty minutes.

Sprints run in Tixio Projects. Kanban for the active sprint, Roadmap view for the quarter, backlog for everything we have agreed we are not doing yet. Custom fields carry priority, module and effort. Recurring tasks handle the maintenance work that otherwise gets forgotten until it becomes an incident.

Architecture discussions happen on Canvas. We have found that the argument about how a system should work resolves about three times faster when everyone is drawing on the same surface instead of describing boxes in a chat thread.

Honest limitation: our code lives in Git and our pull requests live where pull requests live. Tixio is the layer around the code, not inside it.

Design

Design files stay in the design tool, because that is what design tools are for. What moved into Tixio is everything around the file. The brief, the feedback round, the approval, the asset handover, the version that shipped and the version that got cut.

The design team runs a project per initiative with stages that mirror how they actually work: brief, exploration, review, approved, handed off. When a task moves to handed off, the engineer picking it up already has the context because the brief and the discussion are attached to the same item.

Marketing and content

The content calendar is a project in Calendar view. Each piece is a task with custom fields for channel, target keyword, owner and publish date. The brief sits on the task. The draft sits on the task. The three rounds of feedback sit on the task. Nothing lives in an email thread.

Our brand guidelines, tone rules, keyword map and competitor notes are wiki pages. When a freelance writer joins for a project, onboarding is a link, not a call.

Boards do more work here than people expect. The marketing board has the analytics links, the publishing queue, the current campaign checklist and a notes widget, all on one canvas. It is the first tab of the day for that team.

Sales

Sales runs on the CRM add on, 16 people using it daily. Leads come in, move through the pipeline in Kanban, and every call and email is logged against the contact.

The part that only works because it is one platform: when a deal needs a technical answer, the salesperson does not forward an email to engineering and wait. They tag the person in a channel that already exists, and the answer lands next to the deal. Cross department context is the entire argument for consolidation, and sales is where you feel it first.

Customer support and success

Support keeps a wiki section that is effectively our internal answer bank. When the same question arrives three times, it becomes a page. When a page gets long, it becomes a help centre article on the public help guide.

Escalations run as tasks in a shared project that both support and engineering can see. There is no ticket handoff into a black box. The support person who raised it watches it move.

HR and people operations

All 41 HR seats are occupied, which makes this the module we stress test hardest without meaning to. Attendance, leave requests, contracts with version history, onboarding checklists and the org chart all run in Tixio HR.

The onboarding checklist is the piece we would defend loudest. A new person gets a project with their first two weeks already mapped, the accounts they need, the wiki pages they should read in order and the people they should meet. Nobody has to remember to set it up, because it is a template.

Leadership

Leadership does not get a special dashboard, and that is deliberate. They look at the same project reports the teams work in.

The effect is that nobody spends Thursday afternoon building a status deck for Friday. The work and the report are the same object. If a leader wants to know where something stands, they open the project instead of asking a person to summarise it, which means the person keeps their afternoon.

Decisions get written down as wiki pages with dates. This is boring and it is the highest leverage habit we have. It stops the same argument from happening three times in six months.

The rituals that make it work

Tools do not create discipline, rituals do. Ours are simple.

1. Monday planning. Each team reviews its board, moves what carried over, and agrees on what actually matters this week. Twenty minutes, not an hour.
2. Daily async check in. Written, in the team channel, at the start of your day. We are spread across timezones, so a written update is worth more than a call that half the team attends at an inconvenient hour.
3. Recorded meetings. Tixio Meetings records with AI transcription and summaries, and action items sync to tasks. The rule is that if a decision happens in a meeting, it exists as a task or a wiki page within the hour. Otherwise it did not happen.
4. Friday cleanup. Close what is done, reschedule what is not, and be honest about the second one.
5. Monthly wiki gardening. Someone goes through the pages nobody has opened in ninety days and either updates them or deletes them. A wiki with 363 pages only stays useful if you are willing to delete.

What working across companies taught us

Soly is not a single company workspace. It has people from several companies in our group inside it, which is unusual, and it is where Tixio Connect came from. We needed to share a specific project or wiki page with a partner organisation without giving them access to everything, and no amount of clever permission setup solved it properly.

So we built cross workspace sharing, because we were the ones being annoyed by its absence. That is what dogfooding actually produces. Not big visionary features, but the unglamorous ones that remove a daily friction you have stopped noticing you have.

What we do not run in Tixio

Being straight about this matters more than a longer feature list.

• Code and version control live in a Git host.
• Design files live in a design tool.
• Billing and payments run through our payment provider.
• Deep product analytics run in a dedicated analytics tool.
• Accounting is accounting software, as it should be.

Tixio replaces the coordination layer, which is where most of the tool sprawl and most of the wasted hours actually sit. It does not replace specialist systems, and any vendor telling you otherwise is selling you a migration you will regret.

What this costs us

If we ran this team on a typical stack, it would be a chat tool, a docs tool, a project tool, a whiteboard, an HR system and a CRM. For 72 people, that is comfortably past 60 dollars per seat per month once you add the modules everyone eventually needs.

Our actual stack is one platform at 6.30 dollars per user per month on the annual Team plan, plus 5 dollars each for HR and CRM on the seats that use them. The software line is not the main saving though. The main saving is that nobody maintains six sets of permissions, six invite flows and six offboarding checklists.

Should you do this

If you are running four or more tools that all claim to be your team's home base, probably yes, but not all at once. Move one thing first. We would suggest documentation, because a wiki is the lowest risk migration and the highest immediate relief. Then move projects. Chat moves last, because chat is habit and habits move slowly.

And if you try it and find something Tixio cannot do, tell us. There is a reasonable chance we are already annoyed by the same thing, because we are in here every day too.

You can start with 14 days of full access, no credit card required, or book a demo and we will show you our actual workspace rather than a staged one.