About Projexio
Built by people who have run client projects badly enough to want this
Projexio exists because the tools available for client work all assumed the client was not in the room. This page explains what we are trying to do about that, and how we work.
The problem we kept running into
Every project management tool worth using is built on the assumption that the people in the plan work for the same organisation. Internally that is a reasonable simplification. In client work it is the wrong shape, and the consequences are specific rather than vague.
Sharing is coarse, so teams keep an internal board and a tidied version for the client, and one of the two is always out of date. Approval is not a first-class object, so sign-off happens in email and becomes impossible to evidence when it matters. And the person whose approval sits on your critical path costs you a seat licence, so you invite fewer of them and the whole benefit quietly disappears.
None of these are cosmetic. They are the reasons scope drifts without anyone noticing, why overruns surface at invoicing instead of in week two, and why a disagreement about what was promised comes down to two people’s recollections.
What we decided to build instead
One record per project, holding the plan, the deliverables, the decisions, the effort and the approvals. Scope expressed as milestones with acceptance criteria written in language that could settle an argument. Visibility enforced on every individual item so one plan can serve both your team and your client without a second board. Approval as a tracked object with an owner, a date and a permanent record. And no charge for external collaborators, ever.
That is a narrower product than a general-purpose project tool, and deliberately so. It is aimed at work that has a paying client at the end of it, and it makes trade-offs in that direction.
Where we are honest about the limits
We are early. We do not hold a completed SOC 2 or ISO 27001 report and we say so on the security page rather than implying otherwise. There are no native mobile applications yet. Some integrations are in beta and some are still on the roadmap, and the integration directory labels each one accordingly.
We would rather you find that out here than three weeks into an evaluation. If something we have not built is a hard requirement, we will tell you plainly instead of letting a trial run its course.
How we work
Six commitments, stated so you can hold us to them
Say the true thing
We do not publish invented customer counts, borrowed logos or testimonials we cannot attribute. We state plainly which certifications we do not hold. A trust page that overstates is worse than no trust page, because it tells you how we will behave during an incident.
Price so the product can work
Client collaborators are free because charging for the person whose approval you are waiting on would break the thing we built. Every limit is on the pricing page rather than discovered later.
Fewer concepts, used properly
It is easier to ship a hundred shallow features than six that hold up under real use. We would rather the small number of objects in the product — project, milestone, task, approval, time entry — be genuinely well modelled.
Your data is yours
Full export on demand, no support ticket required. We do not train models on your project content and we do not sell it. If you leave, you leave with everything.
Asynchronous by default
We build for teams whose working days barely overlap because that is how we work. Time zone handling, asynchronous approval and written decision records are consequences of that, not add-ons.
A person answers
Support is staffed by people who understand the product and can change it. Questions get an answer, not a link to an article that does not address the question.
Where we are
A distributed team, which is why the product assumes you are too
We work across Asia-Pacific and the Americas. Most decisions are made in writing, handovers are the unit of progress rather than the working day, and out-of-hours calls are rotated on a published schedule. The features that handle time zones, asynchronous approval and written decision records exist because we needed them first.
Hong Kong SAR
HKT (UTC+8)
Monday to Friday, 09:00 to 19:00 HKT
English, Cantonese, Mandarin
Singapore
SGT (UTC+8)
Monday to Friday, 09:00 to 19:00 SGT
English, Mandarin, Bahasa Melayu
United States
ET / PT (UTC-5 / UTC-8)
Monday to Friday, 08:00 to 18:00 ET
English, Spanish
Rest of world
UTC
Asynchronous, answered within one business day
English
We have written up the operating model in our guide to running projects across Hong Kong, Singapore and US time zones. It is what we actually do, not an aspiration.
Get in touch
One inbox for everything
Sales, support, privacy and security all go to the same address. Put the topic in the subject line so we can prioritise it.
Ready to run client work with less friction?
Start a 14-day trial on a real project. No card required, no feature restrictions, and unlimited free client collaborators from the first day.
Questions first? Email support@projexio.org and a person will reply.