Building KlyoChat in Public: What We're Learning

Building in public is a phrase that gets used a lot and meant rarely, so we want to start by being concrete about what it means for us. For KlyoChat it means we talk openly about how the product gets made — what we are working on, why we priced it the way we did, what we got wrong, and what we are deliberately choosing not to do. It does not mean we publish a daily diary of revenue screenshots or turn every decision into content. It means that when you ask why something works the way it does, we would rather give you the real reason, trade-offs and all, than a tidy marketing answer that hides the messy parts.

We are a newer, smaller team building an AI-native, mobile-first chat platform in a category full of mature incumbents. That position shapes everything we are about to tell you. We do not have the longest track record, the biggest community, or the deepest template library. What we do have is the freedom to make decisions in the open and the obligation, we think, to be honest about where we are. This piece is a reflection on what we have learned so far — the lessons, the mistakes, the trade-offs, and the things we are still figuring out.

A note on tone before we go further. This is a first-person company piece, so we use 'we' freely, and KlyoChat is the subject rather than a product we are quietly selling to you. But we have tried hard to keep it honest. You will not find invented user counts, growth rates, or revenue milestones here, because those numbers are not the point and some of them would be made up. The point is the reasoning, and reasoning you can check is more useful than metrics you cannot.

What does building in public actually mean for KlyoChat?

Building in public is not a single act; it is a set of habits about what you share and when. For us it comes down to a few practices we try to keep even when they are inconvenient. We publish a changelog so you can see what shipped and when. We explain our pricing reasoning rather than just listing prices. We name our limits in writing rather than hoping you do not notice them. And when we get something wrong, we say so instead of quietly patching it and moving on.

The word 'public' is doing real work in that phrase. Plenty of companies are transparent internally — they have honest retros and candid roadmaps that customers never see. Building in public means moving some of that honesty outside the building, where it is uncomfortable, because that is where it earns trust. The cost is that we cannot pretend our rough edges do not exist once we have written them down. We think that cost is worth paying.

There is a limit to this too, and we want to be straight about it. Building in public does not mean we share everything. We do not publish customers' private data, we do not pre-announce dates we cannot hit just to look busy, and we do not turn genuine security work into a marketing moment. The line we try to hold is this: we share the reasoning behind decisions that affect you, and we keep quiet about things that are nobody's business or that would be irresponsible to broadcast.

Why are we sharing our journey at all?

The obvious objection is that a newer, smaller company has every incentive to look bigger than it is. Inflate the user numbers, imply more traction than exists, paper over the gaps. We decided to do the opposite, and the reason is not noble so much as practical: in a category with mature incumbents, our credibility cannot come from scale, because we do not have the most scale. It has to come from candor.

When you are the new option, the buyer's biggest fear is the unknown. Is this tool going to exist in a year? Does it really do what the homepage says? What are they not telling me? Every one of those fears is a fear about hidden information. The fastest way we know to reduce them is to volunteer the information before you have to ask — including the unflattering parts. A limit you read about up front is reassuring; the same limit discovered after you have migrated your whole operation is a betrayal.

There is also a selfish-but-honest reason: building in public makes our product better. When we explain a decision publicly, we have to think it through more carefully than if it lived only in a private doc. When we name a limit, people who care about that limit tell us, and we learn what to build next. Transparency is not only a trust strategy; it is a feedback mechanism. The same openness that earns trust also tells us where we are wrong.

• As the newer option, our credibility has to come from candor rather than scale.
• Most buyer fear is fear of hidden information, so we volunteer it before you ask.
• Naming limits publicly turns the people who care about them into a feedback source.
• Explaining decisions in writing forces us to reason more carefully than a private doc would.

What does transparency mean for our pricing?

Pricing is where building in public stops being abstract, because it is the place where a company's incentives and its customers' interests can quietly diverge. We made flat, bundled pricing a core decision, and building in public means explaining the reasoning rather than just posting the numbers and hoping you find them fair.

Here are the actual numbers, plainly. Basic is $19 per month. Pro is $49 per month, or $39 when billed yearly. Business is $129 per month. There is no free plan; instead there is a 7-day free trial with no credit card, so you test the full product rather than a deliberately limited slice. AI agents are included in the paid plans rather than sold as a separate add-on, and contacts are bundled into each tier rather than metered upward.

The reasoning behind that structure is the part we care most about sharing. We chose flat pricing because contact-based metering punishes the exact growth a chat tool is supposed to help you create — a viral month raises your audience and, on a metered plan, your bill along with it. We bundled AI because we think it is the substrate of a modern chat tool, not a premium garnish, so charging extra for it would contradict the whole idea. Those choices cost us margin we could otherwise capture, and building in public means admitting that openly: we are not pricing this way because it is the most profitable structure, but because it is the one we can defend.

Why does flat pricing matter enough to build the company around?

It would be fair to ask why pricing structure deserves so much attention in a piece about building in public. The answer is that pricing is the clearest test of whether a company means what it says. Anyone can write 'we care about our customers' on an about page. Far fewer companies will give up margin to back it up, and pricing is where that choice becomes visible.

Flat pricing matters because of what metered pricing does to behavior. When your bill rises with your contact count, you start treating your own audience as a liability. We have heard from people who built recurring routines to prune dormant contacts purely to stay under a tier — deleting the contacts they worked to earn, as a cost-control exercise. That is the tool fighting its user. A flat plan removes the fight: growing from a few thousand contacts to many more, within your plan's ceiling, does not change what you pay.

We are not claiming flat pricing is universally superior. For a large, steady enterprise with smooth, predictable growth, a metered model can be modeled and managed just fine, and sometimes works out cheaper at the very low end. The case for flat pricing is strongest exactly where our users live: creators and small teams with spiky, unpredictable growth, for whom a single breakout post can blow up a metered budget overnight. Building in public means saying which customer the choice is for, rather than implying it is best for everyone.

What have we learned shipping an AI-native product?

Shipping an AI-native chat platform has taught us things that did not fit our assumptions going in, and building in public means sharing the lessons rather than only the wins. The biggest one: 'AI-native' is a claim you have to keep earning, not a box you check once. It is easy to wire a language model into a product. It is much harder to make the AI genuinely useful in the messy reality of real conversations, real businesses, and real edge cases.

An early lesson was that AI is only as good as the context it has. An agent pointed at a thin or stale knowledge base answers confidently and wrongly, which is worse than not answering at all. We learned to treat the knowledge base as the real product surface — the place where the value is created — and to make it easy to keep current. The model is the engine, but the context is the fuel, and a great engine running on bad fuel still goes nowhere good.

A second lesson was about trust and control. People do not want AI to send replies on their behalf until they trust it, and they only build that trust by watching it work with a human in the loop first. So the useful pattern was not 'AI replaces you' but 'AI drafts, you approve' — a co-pilot before an autopilot. The fastest way to lose someone's trust in an AI feature is to have it confidently say something wrong to a real customer with no chance for a human to catch it. We would rather the AI take first response where you have told it to and stay a draft-and-approve assistant everywhere else, until you decide otherwise.

The third lesson was humility about what the AI cannot do. There are conversations that need a human — an upset customer, a nuanced negotiation, a situation the knowledge base never anticipated. A good AI-native product is not one that tries to handle everything; it is one that handles the routine reliably and hands off the rest cleanly, without the customer feeling shuffled. Knowing where to stop turned out to be as important as knowing what to automate.

• AI-native is a claim you keep earning, not a box you check once.
• An agent is only as good as the knowledge base behind it — context is the fuel.
• Trust is built with a human in the loop: draft-and-approve before autopilot.
• A good AI product knows when to hand off to a human, not just what to automate.

What mistakes have we made and what did they teach us?

Building in public is cheap when you only share the good parts, so here are some honest mistakes. None of them are catastrophes, but all of them taught us something, and pretending we shipped a flawless product from day one would undercut the whole point of this piece.

The first mistake was assuming people would read the limits. Early on we listed what KlyoChat does not do — no native SMS, no native email — in places we thought were obvious, and some people still signed up expecting those channels and were disappointed. The lesson was that naming a limit once is not enough; you have to surface it where the decision actually happens, repeatedly, even at the cost of looking less capable. A limit buried in a footer is not really disclosed.

The second mistake was over-indexing on feature breadth too early instead of depth. There is a constant pull, especially as a newer entrant, to add one more channel or one more integration to look comparable to the incumbents on a feature grid. We learned that a smaller set of things that work reliably beats a longer list of things that half-work. Matching an incumbent's checklist is a trap when you cannot yet match their maturity behind each check.

The third mistake was underestimating how much the mobile experience would matter to our own credibility. We say we are mobile-first, which means the mobile app cannot be a slightly worse version of the product — it has to be a place where real work happens. Every gap between that claim and the actual app is a small dent in trust, and we learned to treat mobile parity as a promise we are accountable for rather than a nice-to-have. Saying 'mobile-first' and shipping a read-only inbox would have made us exactly the kind of company this blog argues against.

How do we decide what to build next?

Roadmap transparency is one of the harder parts of building in public, because the honest truth is that roadmaps change. We would rather tell you how we decide what to build than hand you a list of dated promises we may not keep. A roadmap presented as a contract is a trap; a roadmap presented as current thinking is useful.

Our prioritization is not a formula, but it leans on a few questions we ask about any potential piece of work. We try to favor depth on the things we already do over breadth into things we do not, because that is the lesson our mistakes taught us. We weight feedback from people actually using the product more heavily than feature requests from people comparing spec sheets. And we are honest that some requests, however reasonable, are not on the roadmap at all — native SMS and email being the clearest examples.

Here is roughly how a request travels from your inbox message to something we ship, or decide not to. We share it not because it is unusually clever but because seeing the path is more honest than a black box that occasionally emits features.

1. We collect it in the openFeedback comes through our contact page and conversations with people using the product. We treat a pattern across many users as a much stronger signal than any single loud request.
2. We weigh depth against breadthWe ask whether the request deepens something we already do or pulls us into a new area. Depth usually wins, because reliability is what a newer tool has to prove.
3. We check it against our principlesDoes it fit AI-native, mobile-first, unified, and flat-priced? A request that would force a separate AI charge, for example, is one we will decline on principle even if it is profitable.
4. We ship and log it in the changelogWhen something ships, it goes in the changelog so you can see what changed and when. If we decided not to build something, we try to say so plainly rather than leaving it in limbo.

What are the honest trade-offs of being newer and smaller?

Being a newer, smaller company is not a virtue we are going to spin into a marketing angle. It is a real disadvantage in several concrete ways, and building in public means listing them rather than burying them. If any of these trade-offs are dealbreakers for you, we would rather you know now.

The most obvious is ecosystem. The mature incumbents have years of accumulated templates, a deep marketplace of integrations, agencies who specialize in their platform, and forums full of answers to obscure questions. We do not have that scale of ecosystem yet. If a vast template library and a large community are decisive for you, that is a legitimate reason to weigh an incumbent more heavily than us.

The second is breadth of channels. We focus on messaging — Facebook, Instagram, Telegram, WhatsApp, TikTok, and X — and we deliberately do not do native SMS or email. For a team whose strategy genuinely spans text messages and email newsletters alongside social DMs, an all-in-one incumbent will serve you better. We would rather do the messaging channels well than do everything adequately, but that focus is a constraint, not a hidden superpower.

The third is simply maturity and time. We are still building. Some features that an incumbent has had for years are newer in our product or still on the roadmap. Newer software has fewer miles on it, and while we work hard on reliability, we are not going to pretend that years of being battle-tested at scale count for nothing. They count for a lot, and the incumbents have that and we do not, yet.

What does being smaller let us do better?

Naming our disadvantages honestly earns us the right to name the genuine advantages of being newer, and there are some. We want to be careful here, because this is exactly the place where building-in-public reflections tip over into spin. So we will keep the claims modest and specific.

The clearest advantage is that we built around AI from the start instead of bolting it onto a flow builder designed before language models were useful. We do not carry the weight of a legacy architecture that assumes AI is a separate step. That freedom is why AI agents can be wired into the inbox, the automations, and the comment-to-DM funnels rather than sitting in a walled-off module that exists to justify an add-on fee. It is a structural advantage, not a marketing one.

The second advantage is that we can set pricing without the gravity of a legacy model pulling us toward add-ons. A company that has billed by contacts and sold AI separately for years has revenue built on that structure; changing it is painful. We started with flat, bundled pricing and AI included, so we are not fighting our own back catalog. Being newer made the honest pricing choice the easy one for us, where it would be a costly migration for an incumbent.

The third, quieter advantage is speed of listening. With a smaller team and a smaller user base, a single thoughtful piece of feedback can actually change what we build next. That will be less true as we grow, and we are not going to pretend it is a permanent state. But right now, the distance between you telling us something and us acting on it is short, and that is worth something while it lasts.

• We built around AI from the start, with no legacy flow-builder to retrofit.
• Flat, bundled pricing was our starting point, not a painful migration.
• A smaller user base means a single piece of good feedback can shift the roadmap.
• We name these as modest, current advantages — not permanent superpowers.

How does KlyoChat actually fit into all of this?

Since this is a piece about KlyoChat, it is worth pulling the product into focus rather than leaving it as an abstraction behind the lessons. KlyoChat is an AI-native, mobile-first unified inbox that brings Facebook, Instagram, Telegram, WhatsApp, TikTok, and X into one place. AI agents are included in the paid plans, not sold separately. On top of the inbox sit no-code automation, comment-to-DM funnels, and broadcasts, and the inbox itself is built for small teams with assignment, internal notes, and an AI co-pilot.

Everything we have written about building in public shows up in the product if we have done our job. The flat pricing is the transparency lesson made concrete. The bundled AI is the AI-native lesson made concrete. The mobile app being a real workspace rather than a read-only viewer is the mobile-first lesson made concrete. The point of building in public is not the blog post; it is whether the product matches what the blog post claims.

And the honest limits show up too. KlyoChat does not do native SMS or email. We are newer and smaller than the incumbents, with a younger ecosystem. WhatsApp carries Meta's per-conversation fees on any platform, ours included, because those fees come from Meta directly and no vendor can waive them. We mention all of this here, in a piece about transparency, because leaving it out would make the piece a lie by omission.

Why do we keep a public changelog?

A changelog is the most boring artifact of building in public and one of the most honest. It is a dated record of what shipped, and it cannot be spun. Either the work happened or it did not, and the dates are right there. We keep one because it turns our claims about pace and direction into something you can check rather than take on faith.

There is a discipline a public changelog imposes that a private roadmap does not. When you have committed to publishing what you ship, you cannot quietly let momentum stall, and you cannot retroactively rewrite what you said you would do. It keeps us honest with ourselves as much as with you. A roadmap is a list of intentions; a changelog is a record of follow-through, and the gap between the two is where a lot of companies quietly live.

It is also a form of respect for the people who gave us feedback. When something you asked for ships, you should be able to see it, with a date, without having to ask whether it ever happened. The changelog closes that loop. It is not glamorous, but closing loops is most of what trust is made of, and a feature that ships silently is a thank-you you forgot to send.

How do we think about trust when we cannot lean on scale?

Most software marketing leans on social proof: look how many people use us, look at these logos, look at this growth chart. That lever is largely unavailable to a newer company, and rather than fake it, we have had to think harder about what trust is actually made of when you cannot point to a crowd. The answer we keep arriving at is consistency between what you say and what you do.

Concretely, that means our pricing page should say the same thing our blog says, which should say the same thing the product does. If the homepage promises AI-native and the AI turns out to be a paywalled afterthought, the gap is the betrayal. So we try to make the claims and the reality match, and we try to make the limits as visible as the features. Trust is not built by impressive claims; it is built by the absence of nasty surprises.

We are also wary of a specific trap: borrowing trust through metrics that say nothing about whether the tool fits your work. A precise user count, a funding announcement, a growth rate that rounds to something impressive — these can all be true and still tell you nothing about whether KlyoChat is right for your particular job. Popularity is a signal, but it is not the same as fit. We would rather earn your trust with an honest account of the problem, our principles, and our limits than borrow it with numbers that do not answer your real question.

• Without scale to lean on, trust has to come from consistency between claim and reality.
• The pricing page, the blog, and the product should all say the same thing.
• Visible limits matter as much as visible features — surprises erode trust fastest.
• Popularity metrics can be true and still not tell you whether the tool fits your work.

What is the hardest part of building in public?

It would be dishonest to make building in public sound purely virtuous, so here is the cost. The hardest part is that you cannot hide. Once you have written down your principles, your pricing reasoning, and your limits, you are accountable to them in a way a quieter company is not. Every decision gets measured against the things you said out loud, and that is uncomfortable by design.

There is a competitive cost too. When you publish your reasoning and name your limits, you hand information to competitors who do not extend you the same courtesy. An incumbent can read exactly why we priced the way we did and exactly what we do not do, while telling us nothing in return. We have decided that trade is worth it — the trust we earn from customers matters more than the edge we surrender to competitors — but we are not going to pretend it is free.

And there is the simple discomfort of admitting mistakes in public, which we have tried to do in this very piece. It is much easier to quietly fix a problem than to say 'we got this wrong and here is what we learned.' The temptation to smooth over the rough parts is constant. We resist it because a building-in-public story with no mistakes in it is not a building-in-public story; it is an advertisement wearing the costume of one.

How can you actually give us feedback?

Building in public is a one-way street if it is only us talking, so the most important part of this piece is the invitation to talk back. We genuinely mean it: the feedback from people using the product shapes what we build more than anything else, and right now, while we are smaller, a single thoughtful message can change a priority.

The most useful feedback is specific. 'It is confusing' tells us less than 'I could not figure out how to point the AI agent at my knowledge base from my phone.' Concrete friction, with the context of what you were trying to do, is gold. So is hearing about the limits — if you needed SMS or email and we could not serve you, we want to know, even though it is not something we plan to add, because it helps us be clearer about who we are for.

Here is the most direct way to give it to us, and to judge for yourself whether the principles in this piece hold up against the actual product. The fastest way to have an opinion worth sharing is to run your real work through the trial first.

1. Start the free trial and connect a real channelUse the 7-day free trial with no credit card, and connect one or two channels you actually use, so you are testing on real conversations rather than a demo.
2. Push on the claims in this pieceTest whether AI-native, mobile-first, unified, and flat-priced hold up in practice. The gap between what we wrote and what you experience is exactly the feedback we want.
3. Tell us what broke or confused youSend specific friction through our contact page — what you were trying to do, where it failed, and what you expected instead. Specific beats general every time.
4. Check the changelog laterIf your feedback was part of a pattern we acted on, you should be able to see it ship in the changelog, dated, without having to ask whether it happened.

Where do we go from here?

We will end this honestly, because ending it any other way would undo the whole point. We have things left to prove. Building in public does not make a young product mature, it does not give us the incumbents' ecosystem overnight, and it does not add the channels we have chosen not to build. What it does is make us accountable for the gap between what we claim and what we ship, and accountable is a good thing to be while we close that gap.

The plan from here is not dramatic. Keep deepening the things we already do rather than chasing breadth for a feature grid. Keep AI bundled and pricing flat even when an add-on would make us more money, because that is the principle we are least willing to bend. Keep the changelog honest and the limits visible. And keep listening, especially while we are small enough that listening can change the next thing we build.

If you want the longer story of why we built KlyoChat the way we did, our piece on why we built KlyoChat goes deeper into the four frustrations behind the product. If you want to scrutinize the pricing philosophy specifically, our writing on transparent SaaS pricing makes that argument in full. And if you simply want to find out whether the principles in this piece survive contact with your real work, the fastest way is to try it and tell us where we are wrong.