KasiLabs

What KasiLabs is

KasiLabs is an AI app builder for teams that know their process but have no engineers to turn it into software. Its tagline reads "You know the work. We build the software." You tell it what your team needs in plain words, it turns that into a plan you can read, and it produces a private working version you test before anyone else sees it. The site is written for operators, reviewers, finance and IT staff, and its Services menu lists insurance, SACCOs, logistics, healthcare, manufacturing, accountants, NGOs, co-operatives, education and property. Its clearest worked example is the approval workflow, which also puts it in the territory of process automation: requests, evidence, roles, decisions and what happens after them.

What you build and how

The editor is a conversation rather than a canvas. The home page lays out 4 steps. In step 1 you start in plain words: what people need to get done, what information matters and "what must never go wrong". KasiLabs turns that into a plan you can read. In step 2 you open a private copy, run the tasks that matter and ask for changes in plain words, and "nothing goes live until you say so". In step 3 you choose who can use the app and set a limit on what it can spend. In step 4 you approve the exact version that goes live, see what changed and what to test, and put it live with one click, while the old version stays ready in case you want to go back.

The blog post on building an approval workflow without code shows how that plays out on a real process. It argues you should start with the decision, not the automation: an approval needs a request, required evidence, an authorized decision-maker, explicit states and a result, and the notification and approve button come later. It suggests writing an "approval contract" that records, for one approval, the request, the trigger that makes it ready to submit, the evidence needed before review, the route and its order, the role that may approve, reject, return, cancel or override, the deadline, who acts when the approver is away, the decision options and reasons, what follows approval or rejection, and what happens after a duplicate submission or a failed downstream action.

On states, the post warns against a single free-text status column. It describes a model that runs from draft to submitted, evidence missing, under review, approved or rejected, resubmitted or canceled, and completed, with a rule for who may move a request out of each state and what evidence is needed. A requester may edit a draft but should not approve it. A reviewer may return a submitted request with a reason. A corrected request keeps the earlier decision rather than overwriting it. The same logic gives staff a queue they understand: what needs my action, what is waiting, and why a request cannot move.

The post also separates the request from each decision. The request is one record, and each submission, evidence item, assignment, decision and transition keeps its own actor and time. That lets the app answer questions a flat row cannot: which version of the evidence the approver saw, whether a request was returned or rejected, who reassigned it while the approver was away. It also separates a business decision from a delivery action. An approver can legitimately approve while an email, document creation or connected update fails, so the post says to record the approval once, flag the failed action and give an authorized person a safe retry path, instead of re-running the whole approval.

Its supplier-onboarding example makes this concrete. A supplier request needs Operations review and, under a customer-defined condition, Finance review. The request holds the supplier, requester, category, supporting evidence, assigned reviewers, decisions, reasons and timestamps. Operations can return missing evidence, Finance sees only the cases routed to it, and the owner can cancel a duplicate but cannot silently erase an earlier rejection. The post says plainly that this is illustrative and that "KasiLabs does not ship a prebuilt supplier-approval application". Your policy determines the records, conditions, roles and evidence.

For testing, the post cites OWASP's Authorization Cheat Sheet on least privilege, default denial, permission checks on every request, logging and tests of authorization logic, and says to test authority rather than button visibility. It also tells you to test the rejection, delegation, wrong-role and failure cases privately before the first live request. A related post is titled "Build custom CRM around your workflow", and another covers a procurement approval workflow, so the same approach is not limited to one process.

On the built-in capabilities, the home page says "Files, email, documents, AI, images and search are ready to use" and that you choose what each app is allowed to do. Under usage, it promises you can see where work speeds up, where people get stuck and what to improve next. The site's footer also points to pages on connections, safety and a workflow assessment.

What the pages state

The home page and the blog post state no prices and no plan names, although the navigation carries a Pricing page. They do describe how cost works. The home page says "Every paid action counts against a limit you set, so growth never turns into a surprise bill". When the app reaches your monthly limit, it "pauses extra work instead of running up a surprise bill". The finance card repeats that paid actions stop at the limit you set.

On traceability, the home page says "Reviews, approvals and past versions stay visible. You can move forward and still go back if you need to." The IT card promises that access, releases and past versions stay clear, "with no sensitive keys left exposed". The blog adds that you can choose who can use the app, set spending limits for paid actions and approve the exact release, and that earlier versions stay available.

The home page and blog post name no compliance standards, certifications, hosting regions or integrations, and state no customer counts. Under testimonials the home page says "Real customer stories will appear as our first projects finish", and the cards under it are framed as results every KasiLabs app is "built to deliver" rather than reported outcomes. The blog was published on August 12, 2026 and runs 6 minutes. It is written by "KasiLabs editorial team" and credits Microsoft's approvals documentation, which it says covers first-to-respond, everyone-must-approve, custom-response and sequential approval types, plus reassignment, cancellation, conditional stages and versioned publication. The site's footer says "Copyright 2026 KasiLabs".

One line from the blog is worth quoting for how the vendor positions itself against a suite: "If your process is a standard request with one approver and your organisation already administers Microsoft 365 or another suitable suite, use it." The post adds that a separate tailored app would create unnecessary ownership, and that regulated workflows need the appropriate professional and technical review.

Who it suits and who it does not

KasiLabs suits a policy owner or operations lead whose team keeps chasing one approval through email and spreadsheet columns. It also fits teams in finance, field work and customer service, which the home page names alongside operations and IT, and the Services menu lists sectors such as insurance, SACCOs and logistics. It fits people who want to review a plan in ordinary language, try the result privately, and keep a veto over what goes live and what it can spend. IT teams get a stated focus on access, releases and rollback.

The caveats are straightforward. The pages publish no pricing, so a budget conversation starts with the vendor. No customer stories are published yet, and the home page says so. The service is positioned as "we build the software", so it is closer to a guided build than a self-serve editor you open and drag things around in. The vendor also tells you not to use it for a plain single-approver request your Microsoft 365 setup already handles, and the home page and blog post make no claims about code export, self-hosting or compliance. A team that needs those has to ask before committing.