The internal tool that took three months. Minus the three months.
Think about the last small internal tool your organisation built — a review queue, an approval screen, a planning sheet with real data behind it. Now count where the time went. Almost none of it was the interface. It was finding somewhere to run it, getting sign-in working, passing a security review for a server nobody wanted to own, and arguing about who holds the database credential. Databricks Apps deletes that list.
Where the three months actually went.
We have watched this happen in enough organisations to be confident about the breakdown. If your experience differs, it is usually because the project was abandoned at step three rather than because it went faster.
Illustrative, from projects we have been part of rather than from a study. The proportions are the point: roughly one part building and nine parts everything else. Every one of those nine is a thing Databricks Apps supplies as a default rather than a project.
Python you already know, hosted for you.
Nothing exotic. Dash, Gradio and Streamlit — the three frameworks a data team can already use — with pre-built templates to start from, developed either in the workspace or in your own editor through the Databricks extension for VS Code or the PyCharm integration.
Apps run on serverless compute that is provisioned automatically, so there is no instance to size, patch or forget about. Git version control and CI/CD pipelines are supported, which means an app is a repository like anything else — reviewed, branched, and rolled back when needed.
That last point sounds administrative and is the difference between a tool and a liability. The internal tools that haunt organisations are the ones with no repository, no owner and no way back to last week’s version.
This is the actual product.
Everything above is convenience. This is the bit that removes the five weeks.
- Users are signed in automatically through OIDC and OAuth 2.0 with your single sign-on. You write no login code and store no passwords.
- Access is granted per app, so “who can open this” is a permission rather than an obscure URL.
- App-to-app communication uses service principals that Databricks manages, rather than a long-lived token in a config file.
- Data access goes through Unity Catalog, so the app sees exactly what its user is allowed to see — row filters and column masks included.
- The app inherits the workspace’s networking protections, which means it is covered by controls your security team has already reviewed.
- Data stays within the organisation unless a user chooses to share it, per Databricks’ own statement.
Read that list again as a security reviewer would. Almost every question they would ask has a default answer, and the answers point at controls already approved for the platform. That is why this is fast — not because the hosting is clever.
Four apps that pay for themselves quickly.
The pattern that works: take a decision currently made in a spreadsheet emailed between three people, and give it a screen that reads governed data and writes the decision back. These four come up again and again.
A review queue
Anything with an exception list: invoices that failed a check, orders on credit block, stock below reorder point. The data is already in the lakehouse; what is missing is somewhere to action it and a record of who did.
A planning screen
A forecast from ai_forecast beside the buyer’s own judgement, with the override captured as data rather than lost in a conversation. The overrides become the most valuable training data you have.
A front end for an agent
A question box, an answer with its sources, a thumbs-down that files a real report to the space owner. This is how an agent gets evaluated by the people who know the right answers.
A data quality console
The expectations your pipelines are already evaluating, shown to the business owners of each domain rather than only to the data team. Ownership follows visibility.
Keep one line very clear.
This ties an application’s lifecycle to your data platform. For an internal tool that is exactly right — the platform is where the data, the permissions and the identities already are. For a customer-facing product it is exactly wrong, and the fact that it would technically work is not a reason to do it.
Internal, data-shaped, few hundred users
- Used by named colleagues who already have accounts.
- Its value is the governed data behind it.
- It needs to exist this month, not next quarter.
- Its availability requirement is “working hours”.
Customer-facing, or a product
- Anonymous or customer sign-in, at unpredictable scale.
- A release cycle that must not depend on your data platform.
- A latency or availability commitment to someone outside the company.
- A front end that is itself the thing you sell.
What Databricks publishes, and what it does not
Its customer notes praise one specific thing: getting something real into colleagues’ hands without an infrastructure conversation. SAE International describes turning a retrieval proof of concept into a polished, branded application; E.ON describes demoing and testing with users without extra infrastructure; Addi describes saving several rounds with security and infrastructure teams and sharing in production immediately.
There are no performance, scale or adoption figures published at all. Take the product at the level its own evidence supports: an excellent way to make something real quickly, not a general-purpose application platform.
What an app usually needs beside it.
Data to read, somewhere to write, and an answer to give.
Lakebase
Open-source Postgres with storage and compute pulled apart: branch it like code, scale it to zero, and read the same governed data your analytics read.
Read it →BI and the AI assistantGenie
The place business users live: governed dashboards, natural-language questions answered from curated data, and the shared metric definitions that keep the answers consistent.
Read it →Artificial intelligenceAgent Bricks
A runtime for agents that survive a crash, memory and sessions, tools and MCP servers, search over your documents, traced runs and evaluation by judges and by your experts.
Read it →Where this leads next.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
What people ask about internal apps.
What kind of app is this for?
Internal tools, not your public product. Dashboards with controls, data exploration interfaces, custom reporting, a review queue, an approval screen, the front end of a GenAI assistant — things that need to read governed data, be used by named colleagues, and exist by Friday.
It is deliberately narrow, and that is why it works. The hard part of an internal tool was never the Python.
Which frameworks are supported?
Python frameworks — Dash, Gradio and Streamlit — with pre-built templates, and development either in the workspace or in your own editor through the Databricks extension for VS Code or the PyCharm integration. Git version control and CI/CD pipelines are supported.
So an app is a repository like anything else, which matters the first time you need to roll one back.
Who can see an app, and how do they sign in?
Users are authenticated automatically through OIDC and OAuth 2.0 with your single sign-on, access is controlled per app, and app-to-app communication uses service principals Databricks manages for you. Data access goes through Unity Catalog, and the app inherits the workspace's networking protections.
That combination is the real feature. The reason internal tools take three months is rarely the interface; it is the security review of a server nobody wants to own.
What does it run on, and what does it cost?
Serverless compute, provisioned automatically, so there is no instance to size or patch. Billing follows the platform's consumption model rather than a per-app fee.
The cost question worth asking is not the hosting. It is whether an app that queries a warehouse on every page load is doing so against a materialized view or against three years of raw events.
Is there a catch?
Two worth knowing. First, this ties an application's lifecycle to your data platform, which is right for an internal tool and wrong for a customer-facing product — keep that line clear. Second, Databricks' own customer notes praise it for exactly one thing, getting a proof of concept into colleagues' hands without an infrastructure conversation, and publishes no performance or adoption figures.
Take it at that: an excellent way to make something real quickly, not a general-purpose application platform.
Name the spreadsheet that runs part of your business.
Every organisation has one: emailed between three people, with a decision made in it that matters. Tell us which one. We will build it as an app over governed data in a fortnight, capture the decisions as data, and leave you with a repository, an owner and a way back to last week's version.
- One real decision, one screen
- Sign-in through your existing SSO
- Data read through Unity Catalog permissions
- Decisions captured as data, not conversation
- A repository, a pipeline and a rollback
Databricks, Lakehouse, Lakeflow, Lakebase, Unity Catalog, Genie, Agent Bricks, OpenSharing, Delta Sharing and Lakewatch are trademarks of Databricks, Inc. Apache, Apache Spark, Apache Iceberg and Spark are trademarks of the Apache Software Foundation. Delta Lake and MLflow are projects of the Linux Foundation. SAP, SAP Business Data Cloud and SAP Datasphere are trademarks of SAP SE. PostgreSQL is a trademark of the PostgreSQL Community Association. All other names belong to their owners. Mawkish Technologies is not affiliated with, endorsed by or a reseller for Databricks, Inc. Everything described here is taken from material Databricks publishes; product names, availability and prices change, so check the current documentation before you commit to anything. Screens shown are our own illustrations with sample data, not screenshots.
Our Fenford Standard is the name we give to how we handle Databricks Apps: one accountable partner, from the first meeting to long after go-live.