One workbench for the whole agency Now live · 3-day free trial

What we promise, and what we will not do.

Most companies publish values. This is narrower and more useful: the specific commitments we make about how we build with AI, how we treat you when you need help, and what we are personally on the hook for. Every one of them is something you can hold us to, and every one applies to every product we ship.

Last reviewed September 2026
Applies to Components, portals and tools
Hold us to it support@stacklumen.com

AI is a great tool. We develop and use it responsibly.

We are not hesitant about AI and we are not evangelists for it either. It is the most capable tool we have had in a long time, it is in our products and in how we build them, and the whole question is whether the people using it are honest about what it is doing. Here is how we hold that line.

A tool, not an authority
AI is one of the best tools our industry has been handed, and we use it every day — to build components faster, to catch what we would have missed, and to give a small team the reach of a much larger one. It does not get the last word. A person reviews what ships, and a person is accountable for it.
Responsibly, in the boring sense
Responsible use is a working habit rather than a statement of values: check the output, understand the thing before shipping it, and never put a model somewhere nobody would notice it was wrong. Every component in the library is read by a human before it is published, whatever helped write it.
You always know when it is AI
Where a surface is AI-driven — the studio, an import, anything that generates — we say so plainly in the interface. No agent presented as a person, no generated work handed over as though someone checked it line by line when nobody did.
Your work is not raw material
What you build here is yours. Your components, your client portals, the content inside them: we do not treat customer work as a dataset to be mined, sold, or fed into training something else, and we will not start without asking you first, in plain language, with a real choice attached.
It asks before it acts
Anything that can change your project, spend your money, or speak to your clients in your name should propose rather than assume. We would rather ship an assistant that pauses one time too many than one that is confidently irreversible.
We say what it cannot do
We do not market capability we have not shipped, and when a model is the wrong instrument for a job we will say so instead of selling you the version with AI in the name. The library is honest about which parts are generated and which are hand-built for the same reason.
Novelty is not a reason
A feature being possible is not an argument for building it. If it does not leave the person using it more capable — faster, clearer, with their time back — it does not ship, however good the demo looks.

Support you would actually recommend.

Support is where software companies reveal what they think of the people paying them. Ours is deliberately unfashionable: a small number of humans who answer quickly, know the product, and are allowed to fix things.

A person answers
Every support request reaches a human being who can actually change something. No deflection bot at the front door, no ticket maze designed to make you give up, no first tier that exists to read you the documentation you already read.
Inside one business day
We answer in writing, within one business day, signed by name. If a fix will take longer, the first reply tells you what is happening and when the next one is coming — the silence is the part that actually costs you.
The people who built it
The person answering you has read the component, or wrote it. When a class is behaving strangely in your Webflow project, that is a question about a specific forty lines of CSS, and it is answered from the source rather than from a script.
Help is not a paid tier
Getting a component working in your stack, understanding the tokens, recovering from something we broke — that is support, not an upsell. We do not put the answer to "why is this not working" behind a plan upgrade.
No question is too small
If something is confusing enough to ask about, that is a problem with our documentation, not with you. We would rather answer it four times and then fix the thing that made it necessary.
We will tell you when it is no
If the library does not do what you need, or you would be better served by building it yourself, we will say so directly. A customer we kept by being vague is not a customer we wanted.
When we break it, we say so
Components change. Breaking changes are versioned, written up in the changelog, and told to you by us — before you find them in a client build on a Friday.

The personal part.

Baselumen exists because the gap between what good software can do and what a small team can actually get its hands on is indefensible. The craft exists. It is just priced, packaged and gatekept away from the people who would do the most with it. Closing that gap is the whole job.

So the promise is simple. We only ship things we would be glad to hand to someone we care about. If a component is not good enough to put on a friend's business, it is not good enough to sell. That rule has killed more features here than any roadmap meeting ever has.

Software should leave the person using it better off — more capable at the end of the day than they were at the start, with fewer things to worry about and more of their time back. That is what "makes the world better" means at our scale. Not a slogan about changing the world: a designer who ships on Friday instead of Sunday, a small business whose site finally does its job.

We will price honestly, we will not lock you in, and what you build leaves with you if you go — the components are yours, in plain HTML and CSS, with no runtime of ours in the middle. When we get something wrong, and we will, we will say so first, fix it fast, and tell you what changed so it does not happen twice.

If we ever fall short of any of this, write to me directly. Not a form, not a queue. Me.

Iain Feeney Founder, Stacklumen iain@stacklumen.com

The same commitments, on every product.

We build more than one thing, and a commitment that only holds on one of them is marketing. This page exists on each product, written in that product's own terms and promising exactly the same things.

Holding us to it

If anything on this page does not match your experience of using Baselumen, that is a bug and we want to hear about it: support@stacklumen.com, or iain@stacklumen.com if you would rather it went straight to the top. The enforceable version of our obligations lives in our legal documents, and you can always talk to us.