Hosting for the small apps you build with Claude or ChatGPT — your own private server, one login for your people, backups and rollbacks handled. One flat price. 2026-08-18T15:50:22+12:00 https://oncroft.net/blog/ Rich Chetwynd 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/what-is-an-ai-artifact/ Rich Chetwynd

Artifacts are the pages, calculators, and dashboards your AI builds right in the chat. Here's what they are, how the AI uses them, and where they run out of road.

<p>If you’ve asked Claude, ChatGPT, or Gemini to make you something visual lately, you’ve probably met an <strong>artifact</strong> — even if nobody called it that.</p> <h2 id="what-an-artifact-is">What an artifact is</h2> <p>An artifact is a self-contained piece of HTML and code that the assistant generates and renders <em>inside the conversation</em>, usually in a panel beside the chat. Instead of describing a chart, it draws one. Instead of explaining a form, it shows you a working one. Claude calls them Artifacts; ChatGPT has Canvas; the others have their own version of the same idea.</p> <p>They’re one of the genuinely great things about building with AI. The assistant writes the code, you see the result immediately, and you change it by asking — “make the total bold,” “add a column for tax.” It’s fast, visual, and forgiving.</p> <h2 id="how-the-ai-uses-them">How the AI uses them</h2> <p>Behind the scenes, an artifact is the assistant’s way of <em>showing its work as a working thing</em> rather than as a wall of code. It keeps a live copy it can edit and re-render as you iterate, so the two of you can shape a tool together in a few turns. For sketches, prototypes, and one-off visuals, that loop is hard to beat.</p> <h2 id="where-they-run-out-of-road">Where they run out of road</h2> <p>The catch is in the definition: an artifact runs <em>in your chat window</em>, <em>for you</em>, <em>right now</em>. Which means:</p> <ul> <li>There’s <strong>no server</strong> — it isn’t hosted anywhere someone else can reach.</li> <li>There’s <strong>no database</strong> — anything you type in is gone when you close the tab.</li> <li>There’s <strong>no sharing</strong> — a screenshot or a file isn’t a link people can open and use.</li> </ul> <p>A financial model with fields you fill in and numbers that update is the classic example. On your own screen it feels like software. But you can’t send it to your team, and it won’t remember a thing you entered. It’s a demo of an app, not the app.</p> <p>That gap — between “my AI made a brilliant artifact” and “my team is actually using it” — is exactly what <a href="/artifacts/">Croft</a> closes. <a href="/blog/turn-an-artifact-into-an-app/">Here’s how an artifact becomes a real app →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/turn-an-artifact-into-an-app/ Rich Chetwynd

Your assistant built a brilliant artifact — a financial model, a calculator, a dashboard. Here's how to deploy it to Croft so your team can actually use it, with the data saved.

<p>Say you asked your assistant for a cash-flow model, and it built you a beautiful <a href="/blog/what-is-an-ai-artifact/">artifact</a>: fields to fill in, a running total, a little chart that moves as you type. On your screen, it’s perfect.</p> <p>Then reality lands. You want the three people who run the business to update it together. You want last month’s figures to still be there when you open it. You want to send a link, not a screenshot. And an artifact can’t do any of that — it lives in your chat, runs only for you, and forgets everything the moment you close the tab.</p> <p>You don’t need to rebuild it. You need to <strong>deploy it</strong>.</p> <h2 id="the-whole-move">The whole move</h2> <p>With your assistant connected to your croft, you just ask: <em>“Deploy this as an app on my croft.”</em> The same assistant that made the artifact writes the last mile — and a minute later the model is a real app:</p> <ul> <li><strong>A live web address</strong>, so anyone you invite can open it in a browser.</li> <li><strong>A real database</strong>, so the numbers people enter are saved and there next time.</li> <li><strong>One login</strong>, so it’s shared privately with your team and no one else, through Croft’s <a href="/security/">enterprise sign-on</a>.</li> </ul> <p>Nothing was thrown away. The artifact <em>became</em> the app.</p> <h2 id="why-its-worth-it">Why it’s worth it</h2> <p>Once it’s a Croft app, it can keep growing the way an artifact never could. Ask for a new column next quarter and your assistant edits it. <a href="/connectors/">Connect it</a> to Stripe or your accounting tool to pull real figures. Put it <a href="/automations/">on a schedule</a> to email a summary every Monday. And if you ever leave, you <a href="/blog/your-data-is-yours/">take the whole thing with you</a> — code, database, and all.</p> <p>The artifact was the spark. Croft is where it turns into software your team relies on.</p> <p><a href="/artifacts/">See how artifacts become apps →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-turn-a-google-sheet-into-an-app/ Rich Chetwynd

That spreadsheet doing a job it was never built for? Here's how to turn a Google Sheet into a real app — with a database, a login, and a shareable link — by chatting with AI.

<p><strong>Short answer:</strong> Connect an AI assistant to a host like <a href="/">Croft</a>, hand it the sheet — a link, an export, or just a description of what it does — and ask it to turn it into an app. A minute later it’s a real app on your own server, with a proper database and a login, ready to share with your team.</p> <p>Spreadsheets are brilliant right up until they aren’t: two people edit at once, formulas break, and nobody’s sure which copy is current. When a sheet has become a <em>system</em> — a tracker, a calculator, an intake form — it wants to be an app.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Connect an assistant to your croft</strong> (Claude, ChatGPT, or Grok). <a href="/connect/">How to connect →</a></li> <li><strong>Describe the sheet as an app.</strong> <em>“Turn this stocktake sheet into an app: add items, adjust quantities, flag anything low.”</em> Your assistant recreates the logic — and improves on it.</li> <li><strong>Invite your people.</strong> It’s live at a URL, behind your login. They sign in once and use it.</li> </ol> <h2 id="why-the-app-beats-the-sheet">Why the app beats the sheet</h2> <p>The app has one source of truth (no more “which version?”), a real database so entries are saved for everyone, and per-person access so the right people see the right things. Ask for changes any time and your assistant edits it.</p> <p>Here’s the same idea, worked through with a <a href="/blog/turn-a-pricing-spreadsheet-into-an-app/">pricing spreadsheet →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-share-an-app-you-built-with-ai-privately/ Rich Chetwynd

A screenshot or a file isn't sharing. Here's how to share an AI-built app as a real link that only the people you invite can open.

<p><strong>Short answer:</strong> To share an AI-built app privately, deploy it to a host that gives it a real web address behind a login — like <a href="/">Croft</a> — then invite people by name. They open a link, sign in once, and use it. No public URL, no accounts for strangers.</p> <p>The trouble with an app your AI built in the chat is that there’s nothing to <em>send</em>. A screenshot isn’t the app. A file only works if the other person can run it. And a raw public link would let anyone in. Sharing something real, but keeping it private, needs a proper home.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Deploy the app to your croft.</strong> Connect an assistant and ask it to deploy the app. <a href="/connect/">How to connect →</a></li> <li><strong>Invite your people.</strong> Add them by email on the People page and choose which apps each can open. They sign in with a passkey through your croft’s <a href="/security/">enterprise single sign-on</a>.</li> <li><strong>Send the link.</strong> It’s a real URL they open in a browser, on any device — but only the people you invited can get past the login.</li> </ol> <h2 id="private-by-default">Private by default</h2> <p>Croft apps aren’t public. Access is yours to set, app by app, and everything sits behind one sign-on. Someone leaves the team? Remove them once and they’re out of everything, instantly.</p> <p>Want <em>part</em> of it public — say a survey anyone can fill in, with the results kept private to you? That works too: <a href="/blog/public-form-private-results/">a public page out front, private results behind your login</a>. But the app itself, and its data, stay with the people you choose.</p> <p>This is one of the three things that turn an <a href="/artifacts/">artifact into a real app</a>: a shareable link, a database, and a login.</p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-send-email-from-an-ai-built-app/ Rich Chetwynd

Want your AI-built app to send a confirmation, a reminder, or a report? Here's how to send email from an app on Croft — without putting an email API key in the app.

<p><strong>Short answer:</strong> Add an email provider to <a href="/">Croft</a> as a connector — SendGrid, Postmark, Mailgun, Resend, and more — then ask your assistant to send email through it. The key stays with Croft; your app never holds it.</p> <p>Sending email is one of the most common things a small app needs to do: a booking confirmation, a “your request was approved” note, a weekly summary. You just don’t want the email service’s API key sitting inside an app your AI generated.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Add an email connector.</strong> In your croft, add a connector for your email provider and paste its key — or ask your assistant, <em>“connect our SendGrid account.”</em> Croft holds the key, encrypted.</li> <li><strong>Ask your app to send.</strong> <em>“When a booking is confirmed, email the customer.”</em> Your assistant calls the email API through Croft’s <a href="/connectors/">connector broker</a> — no SDK, no stored key.</li> <li><strong>That’s it.</strong> The key is attached on the way out, and the broker only ever calls the provider’s own domain.</li> </ol> <h2 id="bonus-send-on-a-schedule">Bonus: send on a schedule</h2> <p>Combine it with an <a href="/automations/">automation</a> and your app can email on its own — a daily digest, a Monday report, a reminder the day before something’s due. Ask for a schedule and Croft runs it on time, every time.</p> <p><a href="/connectors/">See connectors →</a> · <a href="/automations/">See automations →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-schedule-automated-reports-from-an-ai-built-app/ Rich Chetwynd

Stop pulling the same numbers by hand every week. Here's how to make an app you built with AI send a report on a schedule — a weekly summary that just arrives.

<p><strong>Short answer:</strong> Give your app a schedule on <a href="/">Croft</a> — a Croft <a href="/automations/">automation</a> — and it runs on its own. Ask your assistant to build a report that pulls the week’s numbers and emails it every Friday, and Croft runs it on time, day after day.</p> <p>Most reporting is the same three steps done by hand over and over: gather the numbers, write the summary, send it. That’s exactly the kind of tedium an app can take off your plate.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Connect an assistant to your croft</strong> and make sure the data lives in a Croft app (a tracker, a log, a sales sheet you’ve <a href="/blog/how-to-turn-a-google-sheet-into-an-app/">turned into an app</a>).</li> <li><strong>Ask for a scheduled report.</strong> <em>“Every Friday at 4pm, pull this week’s totals, write a short summary of what changed, and email it to me and my partner. Keep past reports on a page behind my login.”</em></li> <li><strong>Walk away.</strong> Croft runs it on schedule — even after an update or a reboot. Nothing to remember, nothing to trigger by hand.</li> </ol> <h2 id="make-it-smarter-optional">Make it smarter (optional)</h2> <p>Plug in your own AI key and the report can <em>write itself</em> — a plain-English summary of what moved and why, not just a table of numbers. It reads, summarises, and decides, then sends. It’s an automation, not an autonomous agent: one job, done well, on time.</p> <p><a href="/automations/">See what automations can do →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-host-an-app-built-with-microsoft-copilot/ Rich Chetwynd

Give your whole team the power to build apps from inside Microsoft Teams. Here's how to connect Copilot to Croft so anyone can build apps that are hosted, private, and shared.

<p><strong>Short answer:</strong> Build a Copilot Studio agent, add <a href="/">Croft</a> to it as an MCP tool, and publish the agent to your organisation in Microsoft Teams. From then on anyone in Teams can chat with it, sign in to your croft as themselves, and build apps that are hosted for real — with a database and a login.</p> <p>Copilot is great at generating apps, but on its own it has nowhere to put them. Wiring it up to Croft gives every person in the company a way to build internal tools that actually run and can be shared — without leaving Teams.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Create an agent in Copilot Studio</strong> and add Croft as a Model Context Protocol tool (your croft’s MCP URL, OAuth sign-in).</li> <li><strong>Publish it to your org.</strong> Add the Teams channel, submit for admin approval, and it appears in “Built for your org.” <a href="/connect/copilot/">Full step-by-step →</a></li> <li><strong>Everyone builds — as themselves.</strong> The first time each person uses the agent, they sign in to your croft. Croft’s <a href="/security/">enterprise sign-on</a> scopes every request to that person’s role.</li> </ol> <h2 id="why-it-fits-a-company">Why it fits a company</h2> <p>Apps land on a private server that’s yours, behind one login, with connectors and audit trails — the security an org needs, without a platform to operate. Copilot builds; Croft hosts and governs.</p> <p><a href="/connect/copilot/">See the Copilot setup guide →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-host-a-grok-generated-app/ Rich Chetwynd

Grok can write you a working app, but it can't host it. Here's how to deploy a Grok-built app online, with a database and a login, in a few clicks.

<p><strong>Short answer:</strong> Grok writes the app; it can’t host it. Connect Grok to <a href="/">Croft</a> and ask it to deploy — the app goes live at its own web address, with a real database and a login for the people you invite.</p> <p>Like any assistant, Grok will build you something that works in the chat but has nowhere to live: no URL to send, no database behind it, nothing saved when you close the tab. Hosting is the missing piece.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Connect Grok to your croft.</strong> In Grok, go to Skills &amp; Connectors → New Connector, and add Croft. <a href="/connect/grok/">Full guide →</a></li> <li><strong>Ask it to build and deploy.</strong> Describe the app, or hand over what it already wrote, and say <em>“deploy this to my croft.”</em></li> <li><strong>Share the link.</strong> It’s live behind your login; invite the people who need it.</li> </ol> <h2 id="what-hosting-gives-you">What hosting gives you</h2> <p>On Croft the app gets its own <strong>URL</strong>, a <strong>database</strong> so data persists, one <strong>login</strong> through enterprise single sign-on, plus HTTPS and backups — none of which you set up. Grok builds it; Croft runs it.</p> <p>Prefer Claude or ChatGPT? <a href="/connect/">Same one-link setup.</a> And here’s <a href="/blog/what-is-an-ai-artifact/">what a generated app really is</a> before it’s hosted.</p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-host-a-claude-generated-web-app/ Rich Chetwynd

Claude can build you a working web app, but it can't host it. Here's how to put a Claude-generated app online — with a URL, a database, and a login — in a couple of minutes, without a developer.

<p><strong>Short answer:</strong> Claude builds the app; it can’t host it. To put a Claude-generated web app online, connect Claude to a host built for it — like <a href="/">Croft</a> — and ask Claude to deploy. A minute later it’s live at its own web address, with a database and a login, ready to share.</p> <p>Here’s the wall people hit. Claude will happily build you a working app right in the chat — an <a href="/artifacts/">artifact</a>. It looks like software. But an artifact runs only in your chat window, for you, with nothing saved and no link to share. The moment it’s genuinely useful, you need a <em>home</em> for it.</p> <h2 id="the-steps">The steps</h2> <ol> <li><strong>Connect Claude to your croft</strong> — a one-time setup. In Claude, go to Connectors and add Croft. <a href="/connect/claude/">Full guide →</a></li> <li><strong>Ask Claude to build and deploy.</strong> Describe what you want — <em>“build me a booking app and deploy it to my croft”</em> — or take the artifact you already have and say <em>“deploy this as an app.”</em> Claude writes it and ships it.</li> <li><strong>Open the link and share it.</strong> It’s live at its own URL, on HTTPS, behind your login. Invite the people who need it; they sign in once.</li> </ol> <h2 id="why-you-need-a-host-not-just-claude">Why you need a host, not just Claude</h2> <p>A hosted app has the three things an artifact doesn’t: a <strong>live web address</strong> anyone you invite can open, a <strong>real database</strong> so what people enter is saved, and a <strong>login</strong> so it stays private to your people. On Croft, all three are built in — you don’t set up a server, wire up auth, or manage a database. Claude builds; Croft runs it.</p> <p>That’s the whole loop. <a href="/how-it-works/">See how it works →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-host-a-chatgpt-generated-app/ Rich Chetwynd

ChatGPT can generate a working app, but not host it. Here's how to deploy a ChatGPT- or Canvas-built app online, with a real database and a login, in a few clicks.

<p><strong>Short answer:</strong> ChatGPT can write the app, but it can’t host it. To put a ChatGPT-generated app online, connect ChatGPT to a host — like <a href="/">Croft</a> — and ask it to deploy. It goes live at its own web address, with a database and a login for the people you invite.</p> <p>Whether ChatGPT builds it in a Canvas or just writes the code, you end up in the same place: something that works in the chat but has nowhere to live. No URL to send, no database behind it, nothing saved when you close the tab. Hosting is the missing last mile.</p> <h2 id="the-steps">The steps</h2> <ol> <li><strong>Connect ChatGPT to your croft.</strong> In ChatGPT’s connector settings, add Croft and sign in. (Connecting ChatGPT needs ChatGPT Plus or better — its connector support isn’t on the free tier.) <a href="/connect/chatgpt/">Full guide →</a></li> <li><strong>Ask it to build and deploy.</strong> Describe the app, or paste the code it already wrote, and say <em>“deploy this to my croft.”</em> ChatGPT builds it onto your private server.</li> <li><strong>Share the link.</strong> It’s live behind your login; invite the people who need it.</li> </ol> <h2 id="what-hosting-actually-gives-you">What “hosting” actually gives you</h2> <p>On Croft, the deployed app gets its own <strong>URL</strong>, a <strong>real database</strong> so data persists, one <strong>login</strong> through enterprise single sign-on, plus HTTPS and backups — none of which you set up. ChatGPT is great at writing the app; Croft is where it runs, gets shared, and keeps working.</p> <p>Prefer to use Claude or Grok instead? <a href="/connect/">Same idea, one link.</a> And if you’re wondering what a “generated app” really is before it’s hosted, here’s <a href="/blog/what-is-an-ai-artifact/">what an artifact is and why it isn’t an app</a>.</p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-give-an-ai-generated-app-a-database/ Rich Chetwynd

AI-built apps and artifacts don't remember anything you type in. Here's how to give an AI-generated app a real database so its data is saved and shared.

<p><strong>Short answer:</strong> Most AI-generated apps have no backend, so nothing you type in is saved. To give one a real database, deploy it to a host that provides one — like <a href="/">Croft</a> — and ask your assistant to store the data there. Each app gets its own database, automatically.</p> <p>That financial model your AI built is the classic example: type in numbers, close the tab, and they’re gone. It <em>looks</em> like an app, but there’s nothing behind it — no server, no database, no memory. For a throwaway calculation that’s fine. For anything your team relies on, the data has to stick.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Deploy the app to your croft.</strong> Connect an assistant (Claude, ChatGPT, or Grok) and ask it to deploy the app. <a href="/connect/">How to connect →</a></li> <li><strong>Ask for the data to be saved.</strong> Say what should persist — <em>“save each quote so I can find it later,”</em> <em>“let the team update this and keep the history.”</em> Your assistant adds a table and wires it up.</li> <li><strong>That’s it.</strong> Every Croft app gets its own embedded SQL database on your private server, so data is saved and there next time — for you and everyone you invite.</li> </ol> <h2 id="why-its-not-something-you-bolt-on-yourself">Why it’s not something you bolt on yourself</h2> <p>You don’t provision a database, manage connection strings, or run migrations. The database comes with the app, it’s <a href="/security/">backed up continuously</a>, and it’s <a href="/docs/your-data/">yours to export</a> any time. Your assistant does the writing; Croft provides the place the data lives.</p> <p>A database is one of the three things that turn an <a href="/artifacts/">artifact into a real app</a> — the others being a shareable URL and a login.</p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-deploy-an-app-from-chatgpt-canvas/ Rich Chetwynd

ChatGPT Canvas is great for building an app, but it runs in the chat. Here's how to deploy a Canvas app to a real web address with a database and a login.

<p><strong>Short answer:</strong> Canvas builds the app; it can’t host it. Connect ChatGPT to <a href="/">Croft</a> and ask it to deploy the Canvas app — it goes live at its own web address, with a database and a login for the people you invite.</p> <p>A Canvas is a live workspace where ChatGPT writes and edits your app so you can watch it take shape. That loop is excellent for building. But the result still lives inside ChatGPT — there’s no URL to send, nothing saved between sessions, and no way to let your team in. Deploying fixes all three.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Connect ChatGPT to your croft.</strong> Add Croft in ChatGPT’s connector settings and sign in. (Needs ChatGPT Plus or better for connectors.) <a href="/connect/chatgpt/">Full guide →</a></li> <li><strong>Ask it to deploy the Canvas app.</strong> <em>“Deploy this to my croft.”</em> ChatGPT ships the app to your private server.</li> <li><strong>Share the link.</strong> It’s live behind your login; invite whoever needs it.</li> </ol> <h2 id="what-deploying-adds">What deploying adds</h2> <p>A real <strong>URL</strong>, a <strong>database</strong> so data persists, one <strong>login</strong> through enterprise sign-on, plus HTTPS and backups — none of which you set up. Canvas is where you build it; Croft is where it lives.</p> <p>Not sure what a “Canvas app” really is before it’s hosted? Here’s <a href="/blog/what-is-an-ai-artifact/">what an artifact is, and why it isn’t an app</a>.</p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-connect-an-ai-app-to-stripe/ Rich Chetwynd

Your AI can build an app that takes payments or reads your Stripe data — safely — if the key never lives in the app. Here's how to connect an AI-built app to Stripe on Croft.

<p><strong>Short answer:</strong> Add your Stripe key to <a href="/">Croft</a> once as a connector. Your app then calls Stripe <em>through Croft</em>, which attaches the key on the way out — so the key never appears in the app’s code, and the app never holds it.</p> <p>The wrong way to do this is to let the AI paste your Stripe secret key into the app. That’s how keys leak. Croft’s <a href="/connectors/">connectors</a> exist precisely so they don’t.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Add the Stripe connector.</strong> In your croft, add a connector for Stripe and paste your key — or just ask your assistant, <em>“connect our Stripe account.”</em> The key is held by Croft, encrypted, and never shown to apps.</li> <li><strong>Ask your assistant to use it.</strong> <em>“When someone submits this form, create a Stripe customer and a payment.”</em> Your assistant calls Stripe through Croft’s broker — no vendor SDK, no stored key.</li> <li><strong>Done.</strong> Every request goes out with the key attached last, and the broker only ever calls Stripe’s own domain.</li> </ol> <h2 id="why-its-safe">Why it’s safe</h2> <p>The app can’t spill a key it never had, and for a team, a sensitive connector like payments can require an <a href="/connectors/">admin’s approval</a> before an app or person can use it — with an audit trail of who connected what.</p> <p>The same pattern works for your CRM, email, Azure DevOps, and 45+ more tools. <a href="/connectors/">See connectors →</a> · <a href="/docs/connectors/">The developer detail →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-build-an-internal-tool-without-a-developer/ Rich Chetwynd

The little app your team needs isn't worth a developer's time — but you can build it yourself, by chatting with AI. Here's how to build and host an internal tool without code.

<p><strong>Short answer:</strong> Describe the tool to an AI assistant connected to <a href="/">Croft</a>, and it builds and deploys it for you — no developer, no server to set up. You end up with a real internal app at its own URL, behind your team’s login.</p> <p>Every team has a backlog of tools that never get built: an onboarding checklist, an approvals queue, a job tracker, a simple CRM. Each is too small to hire for and too specific to buy off the shelf, so it lives in a spreadsheet or a group chat. AI closes that gap.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Connect an assistant to your croft.</strong> One-time setup with Claude, ChatGPT, or Grok. <a href="/connect/">How to connect →</a></li> <li><strong>Describe the tool in plain words.</strong> <em>“Build an approvals app: staff submit a request, a manager approves or declines, and everyone sees the status.”</em></li> <li><strong>Share it with the team.</strong> It deploys to your private server, live behind <a href="/security/">enterprise sign-on</a>; you pick who can open it.</li> </ol> <h2 id="why-this-works-now">Why this works now</h2> <p>You don’t write code, manage a server, or wire up a login — your assistant writes the app and Croft runs it, with a database and backups included. When your needs change, you ask for the change and it redeploys. It’s the app you’d have filed a ticket for, built in an afternoon instead.</p> <p>Small business or a team? <a href="/for/small-business/">Here’s what that looks like →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-build-a-private-client-portal-with-ai/ Rich Chetwynd

Give each client their own login to see their projects, files, and updates. Here's how to build a private client portal by chatting with AI — no developer required.

<p><strong>Short answer:</strong> Ask an AI assistant connected to <a href="/">Croft</a> to build a client portal, and it deploys one to your private server: each client signs in and sees only their own projects, files, and updates. You invite clients by name; nobody sees anyone else’s data.</p> <p>A client portal is one of the highest-value things a small business or freelancer can have — and one of the fiddliest to build, because it’s really about <em>access</em>: the right client seeing the right things and nothing more. That’s exactly what Croft handles for you.</p> <h2 id="how-to-do-it">How to do it</h2> <ol> <li><strong>Connect an assistant to your croft</strong> (Claude, ChatGPT, or Grok). <a href="/connect/">How to connect →</a></li> <li><strong>Describe the portal.</strong> <em>“Build a client portal. Each client sees their own projects, files, and a status update from me, and can leave a comment or approve a deliverable. Keep everything else private.”</em></li> <li><strong>Invite your clients.</strong> Add them by email; they sign in with a passkey and land only on their own space.</li> </ol> <h2 id="why-the-access-part-is-safe">Why the access part is safe</h2> <p>You don’t build the login, and you don’t hand-roll “which client sees what.” Croft’s <a href="/security/">enterprise sign-on</a> sits in front of every app, access is granted per person, and a client can never reach another client’s data. Remove someone once and they’re out of everything.</p> <p>Running a business on tools you built yourself? <a href="/for/freelancers/">Here’s the freelancer angle →</a></p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/how-to-add-a-login-to-an-ai-generated-app/ Rich Chetwynd

Don't ask the AI to write your login — it's the easiest thing to get wrong. Here's the safe way to put an AI-generated app behind a login your team can use.

<p><strong>Short answer:</strong> The safest way to add a login to an AI-generated app is <em>not to have the app contain a login at all.</em> Deploy it to a platform where sign-on sits in front of every app — like <a href="/">Croft</a> — so the app never handles passwords, and you just invite the people who should get in.</p> <p>Login and access control are the riskiest code in any app. An AI can write you a login screen, but a botched one is exactly how data leaks — a missed check, a token that isn’t verified, a page that renders before it should. You don’t want that logic living inside an app your assistant generated in a few minutes.</p> <h2 id="the-safe-way">The safe way</h2> <ol> <li><strong>Deploy the app to your croft.</strong> Connect an assistant and ask it to deploy the app. <a href="/connect/">How to connect →</a></li> <li><strong>You don’t build the login.</strong> Every Croft app automatically lives behind your croft’s <a href="/security/">enterprise single sign-on</a>. Identity is checked at a gateway <em>before</em> a request ever reaches the app — so the app never touches passwords or credentials. It can’t ship a broken login page, because it doesn’t contain one.</li> <li><strong>Invite your people.</strong> Add them once by email and pick which apps each can open. They sign in with a passkey — nothing to remember — and every app they’re allowed to use already knows who they are.</li> </ol> <h2 id="why-this-is-better-than-ai-written-auth">Why this is better than AI-written auth</h2> <p>Because there’s no security code in the app for anyone to get wrong, and access is managed in one place. Someone leaves? Remove them once and they’re out of everything. Need finer control? <a href="/docs/roles-and-permissions/">Roles</a> decide who can build, who can approve data access, and who can only use what’s shared.</p> <p>Put simply: let the AI build the app, and let the platform handle the login.</p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/connectors-custom-headers/ Rich Chetwynd

Some APIs need a specific header or an unusual request body. Croft's connector broker now forwards custom headers (and raw bodies) from your app — with the key still held by Croft.

<p>A small but useful change to <a href="/connectors/">connectors</a>: the security broker that sits between your apps and outside APIs now passes through <strong>custom request headers</strong> — and a raw request body — from the app.</p> <p>Why it came up: a user building against <strong>Azure DevOps</strong> hit a wall. Updating a work item there needs a specific content type (<code class="language-plaintext highlighter-rouge">application/json-patch+json</code>) and a body that’s a JSON <em>array</em>, not a plain object. Croft’s standard call — where you pass a set of <code class="language-plaintext highlighter-rouge">params</code> and the broker turns them into a query string or a JSON object — couldn’t express that. So the app couldn’t finish the job.</p> <p>Now it can. When your app calls a connector, it can add two optional fields:</p> <ul> <li><strong><code class="language-plaintext highlighter-rouge">headers</code></strong> — extra headers forwarded to the API, like a specific <code class="language-plaintext highlighter-rouge">Content-Type</code>.</li> <li><strong><code class="language-plaintext highlighter-rouge">body</code></strong> — a raw body sent verbatim, in place of <code class="language-plaintext highlighter-rouge">params</code>, for APIs that want something other than a plain object.</li> </ul> <p>The important part is what <em>doesn’t</em> change. The connector’s credential is still held by Croft and attached to the request <strong>last</strong> — after your headers — so a custom header can never override, replace, or leak the key. The broker still only calls the connector’s own domain. All the <a href="/security/">security guarantees</a> are intact; there’s just more room to talk to fussy APIs.</p> <p>Like everything else on Croft, most people never touch this — your assistant writes the connector call for you. It just means a whole class of trickier integrations now works on the first try instead of the third.</p> <p>The full detail, with the Azure DevOps example, is in the <a href="/docs/connectors/">connectors docs</a>.</p> 2026-08-18T00:00:00+12:00 2026-08-18T00:00:00+12:00 https://oncroft.net/blog/a-private-self-hosted-alternative-to-replit-and-lovable/ Rich Chetwynd

Replit and Lovable are built for shipping public products. If you want AI-built apps that stay private and run on a server that's yours, here's the alternative.

<p><strong>Short answer:</strong> Replit and Lovable are excellent for building and launching public products. If instead you want a small app that’s <strong>private to your team, running on a server you own, with your own AI</strong>, that’s a different tool — and it’s <a href="/">Croft</a>.</p> <p>The AI app builders are aimed at founders shipping something to the world: public URLs, strangers signing up, usage-metered AI. Plenty of great products start there. But a lot of what people build with AI isn’t a product at all — it’s an internal tool, a client portal, a financial model — meant for a handful of people who all know each other. For that, “public by default” and “pay per token” are the wrong defaults.</p> <h2 id="what-private-and-self-owned-means">What “private and self-owned” means</h2> <ul> <li><strong>Private by default.</strong> Every app sits behind <a href="/security/">enterprise single sign-on</a>; you invite people by name. No public sign-ups.</li> <li><strong>A server that’s yours.</strong> Your apps run on your own private machine, not a shared pool — and you can <a href="/blog/your-data-is-yours/">export everything</a> and run it anywhere Docker does.</li> <li><strong>Bring your own AI.</strong> Use the Claude, ChatGPT, or Grok account you already have. No resold tokens, no per-message credits.</li> <li><strong>Flat pricing, no meter.</strong> You’re charged for the ground and the caretaking, not for prompting.</li> </ul> <p>Same “describe it and it’s built” magic — different destination. See the full breakdowns: <a href="/compare/replit/">Croft vs Replit</a> · <a href="/compare/lovable/">Croft vs Lovable</a>.</p> 2026-08-15T00:00:00+12:00 2026-08-15T00:00:00+12:00 https://oncroft.net/blog/the-official-croft-agent-plugin/ Rich Chetwynd

One step to make any compatible AI agent a Croft builder — the tools and the know-how, on an open standard, secured with per-user sign-in.

<p>Connecting an assistant to Croft has always been quick: paste one link, sign in, start building. Today it gets quicker — and smarter. We’ve published the official <strong><a href="/connect/agent-plugin/">Croft agent plugin</a></strong>, a portable <em>Agent Plugin 1.0.0</em> package that any compatible client can install in one step.</p> <p>Most setups hand an agent some tools and hope it figures out the rest. This plugin gives it both halves:</p> <ul> <li><strong>The tools</strong> — the Croft MCP server, so the agent can create apps, write files, deploy, manage connectors, and share data on your workspace.</li> <li><strong>The know-how</strong> — skills that teach the agent Croft’s golden path: how to build and deploy, how to reach outside tools through connectors, and how to share data between apps. It follows your conventions from the very first message, instead of after a few wrong turns.</li> </ul> <p>Two things make this more than a convenience. It’s an <strong>open standard</strong> — not tied to any one vendor, which is the same bring-your-own-AI, no-lock-in deal you get everywhere else in Croft. And it’s <strong>secure by default</strong>: no shared keys, no credentials in the package. On first connect the agent runs per-user OAuth 2.1 against your croft, so each person signs in as themselves and every request is scoped to their <a href="/docs/roles-and-permissions/">workspace and role</a>.</p> <p>The plugin is open source and MIT licensed, up on <a href="https://github.com/richet/croft-agent-plugin">GitHub</a>. If your agent client speaks Agent Plugin 1.0.0, point it at the repository and you’re building on Croft — tools, conventions, and sign-in, sorted.</p> <p><a href="/connect/agent-plugin/">Get the plugin →</a></p> 2026-08-12T00:00:00+12:00 2026-08-12T00:00:00+12:00 https://oncroft.net/blog/your-data-is-yours/ Rich Chetwynd

Cancel any time and take everything: code, database, files, packaged to run anywhere Docker does. Leaving should be boring.

<p>The test of who really owns your software is what happens when you want to leave. On a lot of platforms, that’s the moment you discover the walls: a proprietary format, a half-export, a “contact sales.” On Croft, leaving is deliberately boring.</p> <p>Everything on your croft runs on a private server that’s yours — your apps and your data live there, not in a shared pool with everyone else’s. Cancel, and we hand you a single export of the whole thing: each app’s code, its database, and its uploaded files, packaged as a standard Docker setup that you — or any developer — can run on your own machine or hosting. No proprietary format, no lock-in, nothing to reverse-engineer.</p> <p>The same is true if Croft itself ever went away: you’d still have that export, and it would still run. We’re building Croft to last, but you shouldn’t have to take our word for it — so we made sure you don’t.</p> <p>While you’re here, your data is looked after properly. Every change streams to encrypted, off-site backups, with a nightly snapshot on top, and we run real restore drills — a backup nobody has tested is just a hope. Every deploy is reversible in one click.</p> <p>This isn’t a footnote in the terms; it’s part of the pitch. Security you can trust shouldn’t come with a lock on the door out. You bring <a href="/blog/bring-your-own-ai/">your own AI</a>, you build on a server that’s yours, and you can walk away with all of it whenever you like. That’s what “yours” should mean.</p> <p><a href="/docs/your-data/">Read about your data →</a></p> 2026-08-08T00:00:00+12:00 2026-08-08T00:00:00+12:00 https://oncroft.net/blog/connectors-and-data-governance/ Rich Chetwynd

Let your apps use the tools you already run on — Stripe, your CRM, your email — with the keys held by Croft and admin approval for the sensitive stuff.

<p>Some things belong in one place, not copied into every app: your customer list, your product catalogue, a payment or CRM account. On Croft, a <strong>connector</strong> lets your apps share a data source or reach an outside tool — Stripe, HubSpot, your own API — without the keys ever living in an app’s code. You add each tool’s key to Croft once; it’s kept locked away, and your apps use the connection through a gate that adds the key only on the way out. A leaky app can’t spill a key it never had.</p> <p>For teams, the important word is <em>allow</em>. Not every data source should be open to everyone. Mark a sensitive connector — payroll, your customer database — as needing approval, and anyone can build an app that <em>asks</em> to use it, but it stays switched off until an admin says yes. You can approve a connector for a specific app or a specific person, not the whole company, so new starters and one-off tools don’t get the keys to everything by default.</p> <p>And it’s all on the record. Every connector, approval, and use is logged, so if someone asks <em>“who can reach our billing data?”</em> the answer is a page, not a guess.</p> <p>That’s the quiet difference between a toy and a tool a business can rely on: shared data where it helps the work, a guardrail where it protects the business. It’s the same <a href="/security/">least-privilege principle</a> that runs through the rest of Croft — everything starts locked, and you open exactly what you mean to.</p> <p>Your assistant sets connectors up for you; you just say <em>“connect our Stripe account.”</em></p> <p><a href="/connectors/">See connectors →</a> · <a href="/docs/connectors/">Read the docs →</a></p> 2026-08-04T00:00:00+12:00 2026-08-04T00:00:00+12:00 https://oncroft.net/blog/who-can-do-what-roles-on-croft/ Rich Chetwynd

Owner, Admin, Creator, Member — a small, clear set of roles for giving your team the right access without turning it into a security project.

<p>As soon as more than one person is building on a croft, you need to answer a simple question: who can do what? Croft keeps the answer small. Everyone you invite has exactly one role, and there are four of them.</p> <p><strong>Owner</strong> — the person whose croft this is. Full control, including billing. There’s always exactly one.</p> <p><strong>Admin</strong> — a trusted helper who manages the croft day to day: creating and approving <a href="/connectors/">connectors</a>, inviting and removing people, building apps. Admins can do almost everything except billing and handing over ownership.</p> <p><strong>Creator</strong> — someone who builds and ships their own apps without managing the whole account. They can create, deploy, and share the apps they own, and <em>request</em> access to a connected data source — but they can’t create connectors or approve grants themselves.</p> <p><strong>Member</strong> — someone invited to use the apps that are shared with them. No building, just using.</p> <p>That’s the whole model. It maps onto the two moments that actually matter on a team: the day someone joins, and the day someone leaves. Add a person once and pick what they can open; remove them once and they’re out of everything, instantly.</p> <p>Roles are also what make <a href="/connectors/">data governance</a> work. A Creator can build an app that asks to use the payroll connector, but it stays switched off until an Admin says yes — and the whole thing is on the record. Least privilege, without a spreadsheet of permissions to maintain.</p> <p>Change someone’s role any time from the People page.</p> <p><a href="/docs/roles-and-permissions/">Read the roles reference →</a></p> 2026-07-24T00:00:00+12:00 2026-07-24T00:00:00+12:00 https://oncroft.net/blog/enterprise-security-none-of-the-enterprise/ Rich Chetwynd

Everything starts locked. Single sign-on, least-privilege access, approval gates, and audit trails — built in, so there's nothing for anyone to wire up or get wrong.

<p>The security a big company demands usually comes with a big-company project attached: stand up a platform, wire in an identity layer, keep a team on it. Croft gives your team the same guardrails as a setting, not a project. Here’s the principle behind it: <strong>everything starts locked.</strong></p> <p>Nothing on your croft is open until you open it. A new app starts with access to nothing — it can’t reach your data, your <a href="/connectors/">connected tools</a>, or your other apps until you allow it. People start with access to nothing — you add someone once and they can open exactly the apps you choose, nothing more. Sensitive data sources can require an admin’s approval before any app or person uses them. Access is something you grant, on purpose, and on the record.</p> <p>The riskiest part of any app is the login. On Croft, your apps don’t contain one — the platform does it for them. <a href="/security/">Enterprise single sign-on</a> sits in front of every app, with passkeys instead of passwords. Identity is checked at the gate, before a request ever reaches your app, so an AI-built app never touches security code. It can’t ship a broken login page, because it doesn’t contain one.</p> <p>And it’s all written down. Who was added, who can open what, which data source was connected and approved — logged, so the answer to <em>“who can reach our billing data?”</em> is a page you pull up, not a guess.</p> <p>Underneath, it runs on a private server that’s yours — real isolation, encrypted and tested backups, every deploy reversible in one click. Security you can trust, without a lock on the door out: <a href="/blog/your-data-is-yours/">export everything</a> any time.</p> <p><a href="/security/">Read the full security story →</a></p> 2026-07-15T00:00:00+12:00 2026-07-15T00:00:00+12:00 https://oncroft.net/blog/automations-apps-that-work-while-you-sleep/ Rich Chetwynd

Give any app a schedule and it runs on its own — reminders, nightly syncs, weekly reports — and, with your own AI, it can read and decide for you too.

<p>An app doesn’t only have to run when someone opens it. Ask for a schedule — <em>“email me the day’s bookings every morning at seven”</em> — and Croft runs it on time, day after day, even after an update or a reboot. That’s an automation: a small job your app does on its own, and it’s now built into every croft.</p> <p>The everyday version needs no AI at all. A reminder that goes out each morning. Last night’s sales pulled in from another service at 2am. A weekly summary of survey responses that just arrives in your inbox on Friday. The recurring, tedious jobs quietly handle themselves.</p> <p>Add <a href="/blog/bring-your-own-ai/">your own AI</a> and an automation can think, not just move data around. A morning briefing that gathers what you care about and boils it down to a page before you’re at your desk. A form submission that gets scored and sorted the moment it lands. Notes you drop in through the week, turned into draft posts every Monday. It reads, summarises, and decides — then emails you, alerts you, or updates an app.</p> <p>We call these <em>automations</em>, not “agents.” They don’t wander off and improvise; they do one job well, on a schedule or when something happens, exactly as you set them up. And you set them up the same way you build everything on Croft — by asking your assistant in plain words, not by writing code.</p> <p>It all runs on your own private server, on your flat plan price, using your own AI account for the thinking. No per-run metering, no surprise bills.</p> <p><a href="/automations/">See what automations can do →</a></p> 2026-07-01T00:00:00+12:00 2026-07-01T00:00:00+12:00 https://oncroft.net/blog/public-form-private-results/ Rich Chetwynd

Ask your assistant for a survey and it ships the whole thing — a public link anyone can open, with every response kept private to you.

<p>A lot of small software is really two things stitched together: a page the public sees, and the private side where the results live. A survey and its answers. An RSVP and the guest list. A feedback form and the dashboard you actually read.</p> <p>On Croft your assistant builds both in a single prompt. Ask for a survey and you get a public link anyone can open — no login, no account, nothing tracked — plus a private results page on your croft, <a href="/security/">behind your sign-on</a>, for you and anyone you invite.</p> <p>That split is the useful part. The public side is genuinely public, so you can share it anywhere. The private side is guarded by the same enterprise sign-on that protects everything else on your croft — so responses, submissions, and totals stay with your team, not scattered across a third-party form service you’ll be chasing for an export later.</p> <p>It’s the shape of dozens of everyday jobs: a booking request where customers pick a time and you confirm on a private page; a waitlist where people join with an email and you see the list; an anonymous suggestion box for your team; an event RSVP with a running headcount. Idea to working form in minutes — public page and private results, in one go.</p> <p>The one thing Croft still won’t do is a public product where strangers create their own accounts and log in. Publish a page, collect the responses — yes. Run a storefront for the internet — that’s app-builder territory, and we’ll point you there. The login side is for the people you invite. Deliberately.</p> <p><a href="/how-it-works/">See how it works →</a></p> 2026-06-17T00:00:00+12:00 2026-06-17T00:00:00+12:00 https://oncroft.net/blog/bring-your-own-ai/ Rich Chetwynd

Croft doesn't resell AI or meter tokens. You build with the Claude, ChatGPT, or Grok account you already have — no markup, no lock-in to one model.

<p>Most AI app builders bundle the AI and bill you for it — credits, message limits, per-token charges that surprise you at the end of the month. Croft doesn’t. You build with the assistant you already have and already trust: Claude, ChatGPT, Grok, or anything that speaks the open MCP standard.</p> <p>There are three good reasons it works this way.</p> <p><strong>No markup.</strong> We charge a flat plan price for the ground and the caretaking — the server, the security, the backups. The thinking is your own AI account. Prompt as enthusiastically as you like; the bill doesn’t move.</p> <p><strong>No lock-in to one model.</strong> The AI world moves fast. Whatever’s best next month, you can point it at your croft — the same croft, the same apps, behind the same login. You’re never stranded on a builder’s in-house model because that’s all it supports.</p> <p><strong>One place to build.</strong> You already think things through in your assistant. Connect your croft once and <em>“make me an app that…”</em> ends with a working link. Change your mind next month? Open a chat and ask; it edits the app and redeploys.</p> <p>The same principle runs through everything on Croft. <a href="/connectors/">Connectors</a> hold your keys so they never end up in an app’s code. <a href="/automations/">Automations</a> that need to read and summarise use <em>your</em> AI key, billed by your provider, not marked up by us. And when you leave, <a href="/blog/your-data-is-yours/">you take everything with you</a>.</p> <p>Your AI, your data, your server. We just make them work together.</p> <p><a href="/connect/">Connect your assistant →</a></p> 2026-06-03T00:00:00+12:00 2026-06-03T00:00:00+12:00 https://oncroft.net/blog/turn-a-pricing-spreadsheet-into-an-app/ Rich Chetwynd

The quarterly spreadsheet you email around, turned into a real app your team can use — in one conversation, with no file to lose track of.

<p>Everyone has one: a pricing spreadsheet you rebuild each quarter and email around, never quite sure who’s looking at which version. It works, until three people edit it at once and someone quotes off last year’s numbers.</p> <p>Here’s the whole fix on Croft. Upload the spreadsheet to your AI assistant and ask it to turn it into an app. A minute later there’s a real pricing app — its own web address, a proper database, a tidy interface — running on your croft. You invite your team; they open the link, <a href="/security/">sign in once</a>, and use it. No file to email around, no <em>“which version is this?”</em>, no developer, no server to set up.</p> <p>That’s the pattern for a whole category of tools that were always <em>almost</em> a spreadsheet: a quote calculator that knows your margins, a budget-vs-actual tracker, a break-even model, a commission sheet. Hand your assistant the spreadsheet (or a screenshot, or just a description), say <em>“make this an app,”</em> and it builds it onto your private server.</p> <p>And because it’s a real app now, it can do things a spreadsheet can’t: only the right people can open it, changes are saved for everyone at once, and you can ask for more any time — <em>“add a column for discounts and let Sam approve them”</em> — and your assistant edits the app and redeploys.</p> <p>The spreadsheet was never the problem. Emailing it around was.</p> <p><a href="/prompts/">Grab a prompt to start →</a></p> 2026-05-20T00:00:00+12:00 2026-05-20T00:00:00+12:00 https://oncroft.net/blog/why-we-built-croft/ Rich Chetwynd

An AI can write you an app in minutes. Giving that app a home — a server, a login, a database, a way to share it — is the hard part. That's the gap Croft fills.

<p>Ask an AI assistant to build you an app today and it will. A pricing calculator, a booking sheet, a little CRM — working code, in minutes. Then you hit the wall everyone hits: <em>now what?</em> A chat window isn’t a home. How do you keep it running? Give it a real database? Put it behind a login so only your people can use it? Share it without emailing a zip file around?</p> <p>That last mile — hosting, security, sharing, keeping it alive — is the part the AI can’t do for you. It’s also the part that, for thirty years, meant you had to be big enough to afford a software team. Most good ideas quietly died right there.</p> <p>Croft exists to close that gap. It’s a home for the small apps you build by chatting with AI: your own private server, <a href="/security/">one enterprise sign-on</a> in front of every app, a database, backups, and connectors — all handled. You describe what you want, your assistant writes it, and Croft runs it. When something breaks, you tell your assistant and it fixes itself.</p> <p>We’re deliberately not building the next Airbnb, and we’ll cheerfully tell you if that’s what you need. Croft is for the software <em>in between</em> — the financial model, the client portal, the internal tool, the thing you currently do in a spreadsheet that deserves better. Small software, for a team that knows each other.</p> <p>The promise is simple: enterprise-grade security, none of the enterprise. The apps you need, without waiting on IT, a developer, or another SaaS subscription.</p> <p><a href="/how-it-works/">See how it works →</a></p>