What changed about our client work after we shipped our own product
ChatXport began with a problem at home. Our founder, Fathi, and his wife share a private WhatsApp group where they drop receipts, one for each purchase, with a short description. The plan was that at year-end she would export the whole chat and pull everything together for tax.
When Fathi looked at what doing that would actually involve, it was hours of work. An exported WhatsApp chat is a giant text file with lines like [12/03/2026, 09:14] Me: Vet - Ivar - KSh 3,200 followed by an orphan filename IMG-20260312-WA0011.jpg, with no link between the description and the photo it referred to. Matching them manually across a year of receipts was not a tool, it was a punishment.
He looked for a proper one. The few he found wanted him to upload their family receipts to someone else's server. That was a hard no. So he spent five months building one.
That tool is ChatXport, and we launched it this month. What started as a domestic problem turned into a Baobab Collective product, because we kept finding other places to use it inside the studio: supplier and vendor threads we wanted clean records of, and our own internal studio chats from years of running the business.
The difference between the raw export and a proper viewer is the whole point. Below: the same chat in two views, toggle to compare.
The five months of building, shipping, and using it changed how we work with the clients who hire us for websites and brand work. Not in a vague "we are more mature now" way. In specific, practical ways that show up in the proposals we write, the timelines we quote, and the arguments we have during projects.
We built and shipped our own software product. The discipline of building toward something we have to keep, rather than something to hand off at launch, made us a different kind of agency to hire. This is what that looks like in practice on a client project.
How it became a Baobab product
What started as Fathi's personal project changed when the rest of the studio started reaching for it. The same workflow that helped him pull a year of household receipts together also worked for the studio's own internal chats: vendor threads, project plans, and years of operational knowledge that had been buried in WhatsApp. We were no longer looking at a side experiment. We were looking at a tool the studio relied on.
So we made it formal. Baobab Collective Ltd became the owner. We built the licensing, the website, the support flows, and the refund policy, and we started selling it.
That decision matters more than it sounds. Owning a product means the studio has its own commercial life beyond trading hours for money. It also means you, the client, are not the only thing keeping the lights on, which changes the conversation in the room. Nobody is desperate for your project, and nobody is talking you into scope you do not need. We have somewhere else to put our energy if a brief is not the right fit.
What shipping a product actually means
When you build a product, you build knowing you cannot hand it off. There is no client to take ownership at launch. You will be the one who answers when a license key fails to activate. The refund policy is yours to write. When a bug ships and a fix is ready, the decision about whether to push it now or hold it for the next version will sit on your desk, not someone else's.
That knowledge starts working on you long before launch. Every shortcut during the build becomes a thing you will personally have to deal with later. Every shortcut starts looking expensive.
This is the part most "we will build it and walk away" engagements miss. The discipline of building toward something you have to keep is different from the discipline of building toward a handover.
We spent five months building toward keeping it. That changed how we think about the projects we take on for clients.
Four things that changed about how we run client projects
1. We give timelines we can defend
Before ChatXport, we quoted timelines based on design hours plus development hours plus a buffer. That is fine for the build itself. It misses everything after.
Now we quote timelines that include the part most projects ignore: the two weeks after launch when things break, the content corrections that come in once real users see the site, and the third-party integration that worked in staging and fails on the live domain. We say this in the proposal now. Our own launch this month was the proof.
2. We push back on scope earlier
Every "small addition" during a build looks small in the moment. We used to absorb a lot of them to keep clients happy. Then we shipped ChatXport and started maintaining it. Every "small addition" became a thing we had to test, document, and carry past launch.
Now when a client asks for a feature mid-build, we are honest about what it costs in the long run, not just the build. Sometimes the answer is still yes. Often the answer is "let us ship without it, see what users actually do, and add it in version two if the data says so."
3. We design for the person using the thing, not just the person paying for it
This is the one that surprised us. When you build software for paying users, you find out very quickly that the person who reads your help page is not the person who signed your invoice. The buyer has different priorities than the user. If you only design for the buyer, the user struggles and the buyer eventually hears about it.
Client work has the same gap and we used to miss it. The founder approving the website is not the customer browsing it at 11pm on a Sunday. We now spend more time on the user we will never meet than on the founder we are sitting across from.
4. We ship in versions, not in one big launch
ChatXport launched with a deliberately small surface. We did not try to ship every feature anyone might want. We shipped the version that solved the main problem, and we built the architecture so the rest can be added when real users tell us what they actually need.
We now propose the same approach to clients: launch the version that solves the main problem, watch what happens, and add the rest from real evidence rather than from a wishlist written six months before anyone has touched the site.
What this means if you are hiring us
If you are weighing up studios for a project, here is what we now bring that we did not bring before ChatXport. We build knowing what comes after the launch, because we are the ones carrying it on our own product. When you are deciding who to trust with a website or a brand, that matters. We have already built with those lessons in mind, instead of learning them on your project.
We are still an agency. Most of our revenue still comes from client work, and we still take on websites, brand identity, and digital campaigns the way we always have. What changed is what we bring to those projects. We have learned to be slower with promises and quicker to flag the parts that are going to be harder than they look. We are also more willing to disagree with a brief in the room, instead of building the wrong thing politely.
That is what shipping our own product bought us. It is also what we now bring to yours.
Frequently asked questions
Fathi, our founder. He built it for a problem he had at home. The studio adopted it as a product when we realised we kept reaching for it in our own work, and Baobab Collective Ltd is now the legal owner.
Yes, that is still our main business. ChatXport is a product we own and sell, but the studio runs on client engagements: websites, brand identity, and digital campaigns. The product work happens in parallel and on a separate schedule, so it does not slow down client projects.
No, our rates are set by the work itself. A website still starts at KES 250,000 and a social media retainer at KES 80,000 per month. What you get for that price is different now, because the studio that does the work has shipped its own software and brings those lessons into the project. Same price, more experience.
We protect client schedules deliberately. The product side and the client side run on separate sprints. Most clients do not even know there is a product part of the business unless they ask, because their delivery dates do not move because of it.
Sometimes, depending on the brief. We are not a software development house and we do not take on six-month custom builds on a whim. If your business needs a real software product, we will tell you honestly whether it is something we should build, something you should build internally, or something that already exists for less than the cost of building.
Founders and business owners who want a partner that will tell them the truth and ship something they can be proud of. We work well with clients who care about the user as much as they care about the homepage. We work less well with clients who want a vendor that says yes to everything.
The bottom line
You can hire an agency that has only ever built things and walked away. Or you can hire one that has built, shipped, and lived with the consequences of its own work. The first kind is cheaper to find. The second kind is harder to spot but easier to work with, because they have already made the mistakes you would otherwise pay them to make on your project.
ChatXport was not built to make us a better agency. That is just what happened. If you are starting a project this year and you want a studio that will tell you what you need to hear, not what you want to hear, that is the version of Baobab Collective you would be working with.