At Dropbase we wondered, how is it possible for one of the world’s most popular programming language and the language with which we build intelligence not a first-class citizen for internal tools building platforms? As AI development continues to grow, more developers will be proficient in Python and will need platforms to help them build internal apps and automations. At Dropbase, we set out to be a new platform for internal tools building designed specifically for Python developers.
Python is known for its simplicity and versatility, making it great for backend development, data processing, AI, and machine learning. Its user-friendly nature and powerful libraries make it perfect for rapid prototyping. Plus, when it comes to data processing and analysis, there are no libraries out there as extensive in the Python ecosystem to crunch data as Pandas and NumPy. And because Python’s syntax is clean and simple, developers often have no trouble picking it up. Internal tools are tools that require the quickest turnarounds, and Python is fantastic for rapid development and prototyping.
The most concise way to summarize the challenges would be in 2 words: abstraction imbalance. The balance is quite challenging to get right and this presents an opportunity. On the one hand, you can build anything with code, but it would take a long time and would be inconvenient. On the other, you can provide high level abstractions on everything, minimizing the amount of code required, but it trades off the freedom and expressiveness that developers expect. We think there are at least 4 factors that can be fined-tuned to reach a better abstraction balance for internal tools: code centricity, app building mental models, UI artifacts, and repetition.
Most app building platforms work the same way. You drag and drop some UI components in a canvas, wire them up with data fetchers, and deploy. It sounds easy, but I’ve had CTOs of unicorns tell me otherwise. And while they target developers, the reality is that there’s an awful lot of mouse movements, dropdowns, and button clicks required to write queries or fetch data, which doesn’t quite give you the expressiveness, flexibility, and familiarity of code that a developer would expect.
There are other platforms that are heavier on code, but they lean so heavy on code that it takes significantly more skills, time, and learning curve to build an app that gives you enough data context, allows you to lookup data, and let you perform actions on your data. And to actually build an app for end users that has great UX and it’s delightful to use, you would need at least 2 developers to build an app, unless your backend was also Javascript. Javascript however is less commonly used for backends of intensive data processing products.
When using many of the popular app development tools, it often feels like creating a full-stack JavaScript application, except for the need for boilerplate code or infrastructure management. However, this approach doesn't align naturally with the mental models of Python developers. Since many internal tool-building platforms prioritize JavaScript, the app development process is structured around concepts and practices familiar to JavaScript and its developers. As users inevitably request Python support and platforms accommodate this request, Python code runs but it does so mostly as a separate environment. It’s as if you had a fullstack Javascript app that called an external Python function. The app-building mental model remains centered on JavaScript, which isn’t as intuitive to Python developers.
Building UIs by dragging and dropping UI components is so easy that many developers tend to overcomplicate their designs, resulting in dashboards that scream “look-at-all-the-cool-components-we-added” energy - the same energy we see in corporate Business Intelligence (BI) dashboards that have extended development cycles and suffer from low utility density, user adoption, and app longevity. And the more vanity components and styling options there are available, the lower the density, as unnecessary components and visual flair is added.
On the other side of the spectrum, for app-building platforms that are more code centric, adding UI components is so hard that you just don’t add enough. This means users will often lack the essential data context required to correctly and conveniently perform an action. For example, to trigger a refund, you might just have 1 user input which asks for the user’s email. But when you have multiple records of the same email as it often happens, how would an operator determine if they are about to refund the right customer without seeing more data context, some information about the user or whether the emails are associated with valid (or invalid) payment information.
When you use internal tools, you almost always use them the same way. You tend to perform roughly the same 3 steps:
However, with most app building platforms you need to re-build features that let you take the same set of steps. For each new app you create, you lay out a table (or a data view), lay out multiple input fields to lookup data by different fields, and configure multiple queries for simple tasks such as looking up data, making simple edits, or refetching data. You might wonder why these 3 fundamental steps aren't already built by default. I wonder if it’s really necessary to lay out user input, write a function, and wire the 2 together just so I can perform a customer lookup. And then write another function to perform a data refetch to run after data is updated. The list gets long, so flipping the perspective could help: How often do you NOT need to lookup a customer or refetch your view after you’ve updated the customer’s info? There seems to be scope for improvement.
We did some research and after talking to people we summarized a list of the 30 most common customer success, support, and operations tools. We realized 2 main things: the more obvious one is that these teams are all building the same kinds of tools and require the same components, and the less obvious one is that the components can be grouped into 3 and map one-to-one to the steps that operators perform each time they use these tools: a data view to get data context, a search bar to lookup information, and a sidebar from where they can trigger actions based on the data. Of the other components used frequently aside from tables, search bars, and action widgets, most were low value - they were nice to have, but users didn’t really care about them.
Another insight is that there are orders of magnitude more Javascript developers who understand frontends and can at least build something basic, relative to Python developers. The skill gap to build a working fullstack app is larger for a Python developer than it is for a Javascript developer. A tool that closes that gap should in theory provide higher incremental value, as Python developers could now do things they just couldn’t without investing a significant amount of time or asking somebody else to help.
Our core belief is that customer success, support, and operations apps should be built to just get the job done as quickly, effectively, and delightfully as possible, maximize utility and minimize effort and cost. If we had to come up with a metric for success of a deployed internal app, it would be called “Effectiveness Score (ES)”, which would comprise of at least 4 key factors multiplied together: developer productivity (P), app utility (U), intuitiveness (I), and time efficiency (T). With this in mind, we set out to design a new kind of internal tool builder - one that’s specifically focused on customer success, support, and operations use cases, such that if you need to build an app for any of these teams, Dropbase is the tool to build them with if you want to maximize your per-app ES.
Dropbase’s app-building paradigm is inspired by products such as Retool and Airplane, yet significantly differ from them. It recognizes what makes them great while improving upon them by focusing on what’s essential to effectively get the job done. It strikes a better abstraction balance on the factors that matter to support customer operations. Placed in a 2x2 positioning matrix with these products, Dropbase would be in whichever quadrant has the highest expressiveness AND abstraction usefulness i.e. in the sweet-spot between them.
Dropbase is built specifically for Python developers like us. It’s more in tune with our app-building mental models. Developers can build beautiful and useful UIs without React or Javascript. It’s simple, practical, and to the point. It’s flexible and powerful, yet lightweight and beautifully designed. It has a small learning curve and it lets you build apps in 3 simple steps.
Dropbase lets you build fullstack apps with just SQL and Python. At the core of it is a new lightweight web framework - the Dropbase Python Web Framework - that we purposefully built to enable this capability and this paradigm of fullstack app development with Python. Our framework allows Python functions to control UI components and bind to the latter to trigger actions. We’ll write a separate blog post on this later.
We’re inviting a few companies to sign up and try Dropbase. We don’t have a self-serve cloud version yet so we are doing white-glove deployments. Because of this, we are prioritizing companies that build heavily on Python, or have a pressing need to build internal tools or turn their critical Python scripts into deployed apps. To request early access, join the waitlist.
