The Death of the Form: Why Cloud SaaS Turned Databases Back Into Spreadsheets

FileMaker invented the form in 1985

Nashoba Systems wrote a database called Nutshell for MS-DOS in 1982. It handled text indexing and basic card layouts for non-technical users. When the Macintosh arrived, Nashoba rewrote the engine from scratch. The result was FileMaker 1.0 in 1985.

FileMaker introduced the WYSIWYG layout. Users toggled between Browse Mode for data entry and Layout Mode for drawing the form on a visual canvas. One table could have ten distinct layouts: a compact phone list, a detailed customer record, a packing slip, and a formal invoice. The data stayed the same. Only the presentation changed.

This was the separation of layout from data. Before FileMaker, editing a form meant editing the code that drew the screen. After FileMaker, a single table could look however the operator needed it to look.

The Macintosh made this matter. What appeared on screen matched the LaserWriter output dot-for-dot. A printed customer form looked like the on-screen customer form. For the first time, a database record was also a document.

Why forms beat grids

A grid shows fifty records at once. That sounds efficient. In practice, it creates problems that forms avoid.

Cognitive load. A grid asks you to scan fifty rows and sixty columns. A form shows one record. Your attention stays on the data that matters right now. When you fill out a customer dossier, you do not need the other forty-nine customers visible.

Layout hierarchy. A form groups related fields together. Name and address sit in one compartment. Billing details sit in another. A grid flattens everything into a single row. The only hierarchy is column order. That order applies to every record the same way.

Focused entry. Data entry in a form means filling out one record at a time, with tab stops that follow the logical order of the fields. Data entry in a grid means clicking into a cell and hoping you are in the right row.

Print fidelity. A form can be printed as a document. A grid prints as a table. When the output needs to look like an invoice or a customer card, only a form produces it directly.

FileMaker understood this in 1985. By the 1990s, Microsoft Access added its own form builder with drag-and-drop controls and a pixel-positioned canvas. FileMaker Pro 3.0 introduced portals in 1995: scrolling windows that showed related child records inside a parent form. The form was the standard interface for database work.

The Bento lesson

In January 2008, FileMaker Inc. launched Bento, a $49 consumer database for Mac OS X Leopard. It dropped relational complexity. The focus was visual comfort. Drag-and-drop card trays. Customizable themes: brushed metal, leather, legal pad. Zero-configuration sync with Apple Address Book and iCal.

Bento proved something. Non-technical users loved structured records when the records lived in visual trays instead of flat tables. Photographers, consultants, and small-business operators used Bento because it felt like a physical object on a desk.

In 2010, Bento launched for iPad and became a well-reviewed tablet productivity app that year.

On September 30, 2013, FileMaker Inc. discontinued Bento. The most common explanation: at $49, Bento was too successful. Small-business operators were buying Bento instead of FileMaker Pro, which cost $299 to $499. FileMaker Inc. never stated the reason publicly. The result was tens of thousands of users stranded without a visual personal database on macOS.

That diaspora never found a proper home. Some moved to Tap Forms, which closely modeled Bento's templates. Others went to spreadsheets. Many ended up in the cloud tools that launched in the following years. For a longer account, see the desktop database timeline.

Cloud SaaS killed the form

Airtable launched in 2012 as a "spreadsheet with typed columns." Notion added inline database blocks in 2018. Both prioritized the grid view. The grid was the primary interface. Forms, when they existed at all, were afterthoughts: a simple input page that fed into the grid.

This was a regression. Forty years of form-driven design vanished in favor of colorful spreadsheets.

The reason is economic. A grid is cheap to build. You render column headers and rows. Every table looks the same. A form layout requires a visual editor, a positioning engine, and per-table design work. Cloud SaaS companies optimized for fast launches and low development cost. Grids shipped faster.

The grid brought other costs with it. Per-seat pricing climbed to $20 to $45 per user per month. Records lived on someone else's server. When Wi-Fi dropped or a cloud region had an outage, work stopped. Automation runs were capped and paywalled. The Airtable alternatives page covers these trade-offs in detail.

Mac users had even fewer options. Microsoft never released Access for macOS. The question comes up regularly, but there is still no official answer. After Bento's discontinuation, Mac users who needed a visual database had almost nowhere to go.

The result: a visual database in 2020 looked worse than a visual database in 2008. Bento had card trays and themes. Airtable had a colored spreadsheet. The data got typed columns and relational links, which was an improvement. The interface for entering and reading that data got worse.

Why modern tools feel sterile

Bento used physical metaphors. Records sat in trays. Themes gave each database a material presence. The layout told you what kind of data you were looking at before you read a single field.

Cloud databases use the same flat white grid for a customer list, a product catalog, and a project tracker. The only visual difference is the column names. There is no spatial hierarchy, no grouping, no compartments. Everything is a row.

This matters for daily use. An operator who opens the same database fifty times a day needs orientation cues. Grouped fields, rounded compartments, and consistent card layouts reduce the effort of reading a record. A flat grid forces you to re-parse the column headers every time.

Consider a customer database. The operator needs contact details, order history, and notes. A form shows each group in its own compartment. A grid puts them in columns that scroll off-screen.

The sterility is a cost-driven design choice. Building a form editor is hard. Rendering a grid is easy. Cloud tools chose the easy path and called it "flexible."

How Dosirak brings the form back

Dosirak is a local-first desktop database. A project is a folder on your disk with TOML schema files and a SQLite database. The app runs natively on macOS and Windows.

Computed responsive grid. The form layout uses a computed grid that positions fields in compartments. Fields are grouped by meaning. The column index does not control placement. The layout adapts to the window size without manual repositioning.

Rounded compartments. Related fields sit inside compartments with rounded walls. Name and contact details in one compartment. Dates and status in another. The visual grouping tells you what belongs together before you read the labels.

Cards and lists for browsing. Card views show records as individual tiles with key fields visible. List views show a compact table for scanning. Both serve as entry points to the form.

Form view for editing. Each record opens in a focused form. One record at a time. Tab stops follow the field order. The form is the primary editing interface, as it was in FileMaker in 1985 and Bento in 2008.

Local-first means no latency. Every keystroke writes to a local SQLite database. There is no round-trip to a cloud server. Fields update instantly. For operators accustomed to the half-second delay of cloud forms, this difference is immediate.

An embedded MCP server lets agents read the schema, query records, and file new entries through the operator's approval. The human uses forms and cards. The agent uses structured queries. Both work against the same SQLite file.

Forty years of circle

In 1985, FileMaker separated layout from data and gave operators a visual form. By the mid-1990s, forms were the standard database interface. Access, FileMaker, FoxPro, and Paradox all had them.

In 2008, Bento showed that forms worked for everyday users. In 2013, FileMaker killed Bento. In 2012, Airtable launched a grid. By 2020, the grid was the default again.

The form was abandoned because grids are cheaper to build and sell.

Local-first desktop software does not have the same constraints. There is no cloud infrastructure to maintain. There is no multi-tenant grid renderer to optimize. The engineering effort can go into the layout engine instead of the server fleet.

The form is worth the effort. Bento proved it. The cloud forgot.

The form, on your desk

Dosirak is a local-first desktop database with focused forms, local storage, and agent access. See what Dosirak does.

Questions