You already did the hard part. The pricing logic, the eligibility rules, the project estimates — whatever your Google Sheet calculates, it works, because you've been refining it for months. The problem is everyone who needs the result but shouldn't be anywhere near the formulas: colleagues who type over calculated cells, clients you'd rather not send a raw spreadsheet, prospects on your website who will never open a Sheet at all. Going from Google Sheets to app sounds like a project for a developer and a quarter. It isn't. If the model already works, you can import your Google Sheet and have a usable web app the same afternoon. Here's the realistic path, step by step.
What You Need Before You Start
Three things, none of them exotic:
- A working Sheet. The model should already calculate correctly when you change the inputs by hand. An afternoon is enough to build an app from a working model — it is not enough to also debug the model.
- A clear idea of the audience. Who will use the app, and which handful of inputs and outputs do they actually need? An app that exposes five fields is built faster and used more than one that mirrors the whole workbook.
- A free airrange account. You can sign up and build unlimited apps for free; a paid plan only comes into play when you want to publish and share the result.
One structural tip before you import: make sure every input your users will change is a plain cell (not buried mid-formula), and give the key cells recognizable labels in neighboring cells. Clean inputs make the next two steps almost mechanical.
Step 1: Import Your Google Sheet
In airrange, you connect your Google account and import the Sheet you want to build on. The data and formulas are synced into airrange, and from that point the imported model is the calculation engine behind your app — the same cells, the same formulas, nothing rewritten. This matters more than it sounds: with most app builders, "supporting" Google Sheets means storing your rows while you rebuild the logic in their own expression language. Here the spreadsheet logic is the app logic, which is why the import takes minutes instead of days.
Two things worth knowing about how the import behaves. First, sync is manual — after you import, the app works from the imported copy, and when you change the model in Google Sheets you sync those changes over deliberately rather than having every half-finished edit go live. For a calculation model, that's a feature: you decide when a new version ships. Second, the imported data is stored encrypted on EU servers in Frankfurt, which tends to matter to anyone with a GDPR checklist.
Step 2: Choose Inputs and Outputs
This is the step that turns a spreadsheet into an interface, and it's mostly a selection exercise: you pick which cells are user inputs and which cells display results. An input cell can become a text field, a dropdown, or a slider; a result cell displays whatever the model calculates from the inputs. Everything in between — the lookup tables, the intermediate calculations, the assumptions tab you'd rather nobody touched — simply doesn't appear in the app.
Be ruthless here. The discipline question for every candidate field is: does the user need to change this, or do they just need the consequence of it? A quoting model might have forty assumptions and need exactly six inputs: quantity, product tier, region, contract length, and two options. Six inputs is an app someone fills out on their phone without being asked. This selection step is also where the permission problem you had with the shared Sheet quietly disappears — people can only touch what you exposed, and the formulas never ship to their browser at all.
Step 3: Design the Interface
With inputs and outputs chosen, you arrange them into an actual interface: drag and drop the elements into a layout, group related fields into sections, add labels and explanatory text, and pull in a chart where a number alone doesn't tell the story. The result is responsive, so the same app works on a laptop in the office and a phone in the field.
The temptation in this step is to recreate the spreadsheet's look. Resist it. The people you're building for don't think in rows and columns — that's why you're building this. A good order of work: put inputs at the top in the order a person would naturally answer them, results below, and rename everything from spreadsheet shorthand ("Adj. base p.a.") to human language ("Annual base price"). Half an hour of layout work here is the difference between an app people use and an app people ask you to explain.
Step 4: Publish, Share, Embed
When the app looks right, you publish it. From there you have three distribution paths, and picking one takes minutes: share the app via link with the people who need it, embed it on your website with an iframe, or — if developers want the logic in their own workflows — expose the model's calculations as a REST API. The link is the right choice for internal tools and client-facing calculators; the embed is how a pricing or ROI calculator ends up on your marketing site.
This is also where the free/paid line sits: building is free and unlimited, publishing and sharing requires a paid plan, which starts at €59 per creator per month (billed annually). The Google Sheets connection with sync is part of the Plus plan at €99 per creator per month. Notably there's no per-user pricing on the consumption side — the people using your app don't need licenses, which is exactly what you want when the audience is "every visitor to our website."
Import or Live Data Source? Know Which One You're Doing
One distinction saves a lot of confusion later. What this guide describes is the import path: your Sheet becomes the app's calculation model, and you push updates by syncing. That's the right shape when the Sheet is the logic — a calculator, a configurator, an estimator.
There's a second, different way airrange works with Google Sheets: connecting a Sheet as an external data source, where a table your team maintains in Sheets — a price list, a rate table — feeds live into apps as reference data. That's the right shape when the Sheet is the data rather than the logic, and it's covered in more depth in our post on using Google Sheets as a database. Many real apps end up combining both: an imported model doing the calculating, a connected table supplying the rates. For an afternoon build, start with the import path — you can add a live table later without rebuilding anything.
A Realistic Afternoon
Here's how the hours actually break down for a first app from a healthy model: tidying the Sheet's inputs, maybe thirty minutes. Import, minutes. Choosing inputs and outputs, under an hour — most of it deciding what to leave out. Layout and labels, an hour. Publishing and testing the share link on your phone, thirty minutes. That leaves slack for the inevitable "actually, let's also show the monthly figure" — and you make that change in the Sheet, sync, and the app follows.
The same flow works identically if your model lives in Excel instead — airrange treats Excel models and Google Sheets as equal citizens, which is rare among app builders and useful the day your team switches tools. For the fuller picture of the Google Sheets path — including how it compares to AppSheet and Glide — the Google Sheets app builder page is the reference.
The honest summary: the afternoon isn't spent building an app. It's spent choosing what to show, from a model you already built. Import your Sheet, pick six fields, arrange them, publish — and the spreadsheet you've been emailing around becomes something people just use.