A post titled "Introduction to Snowflake App Runtime: Deploying Full-Fledged Web Apps Next to Data with a Single Prompt!" trended on Zenn. Running apps "next to" a data platform is far more than a novelty. Even when enterprise data is centralized in a data warehouse, frontline operations remain scattered across Excel and spreadsheets, maintaining redundant workflows where data is exported to CSV, processed, and uploaded back. Business applications running near data offer a practical solution to close this gap between data and operations.
In custom development projects, situations where "BI dashboards were built, but frontline staff still enter data into spreadsheets manually" or "apps were built on separate infrastructure, resulting in duplicate maintenance of data pipelines and access permissions" are common. When supporting systems through custom development, we view this not merely as whether one can build an app, but as an architectural challenge: maintaining governance and access controls while building internal business apps, establishing operational routines, and handing them over smoothly. Connecting with our earlier pieces on distributing agents across data platforms in Client projects: Data platform design with Snowflake Agent Sharing (GH Media), internal tool integration in Client projects: Integrating internal SaaS with the Notion Developer Platform (GH Media), and DX implementation strategies in SME DX success stories (GH Media), this article organizes support for building internal business apps to move beyond spreadsheets into a dedicated service package for client development.
Why run applications next to data now?
| Dimension | Apps outside data platform (traditional) | Built in-house next to data (2026) |
|---|---|---|
| Data integration | Manual CSV export and import | Direct connection on the same platform |
| Permissions | Re-implemented in the app layer | Inherited directly from data platform |
| Dual management | Spreadsheets remain in use | Data entry unified in the app |
| Infrastructure | Built and maintained separately | Colocated on the data platform |
| Governance | Copies scattered everywhere | Trackable through audit logs |
| Deliverable | Siloed with duplicate maintenance | Data and business operations unified |
In short, having a dashboard is entirely different from frontline staff running daily operations directly on data. In custom development, securing permissions and audits at the platform level, migrating frontline data entry and approval workflows into the app, and embedding it into operations prior to handover has become an essential quality standard. This guarantees in-house applications where data and operations are truly unified as a core deliverable.
Three structural changes beneficial to custom development projects
Structure 1: From "CSV export/import" to "direct data connection"
Exporting, processing, and re-importing data degrades data freshness and invites operational errors. In custom development, apps colocated on the data platform allow teams to read and write live data directly.
Structure 2: From "re-implementing app permissions" to "inheriting platform permissions"
Creating duplicate access control systems inevitably causes discrepancies. In custom development, applications inherit data platform roles and row-level security, ensuring centrally managed permissions.
Structure 3: From "lingering spreadsheets" to "consolidated data entry"
If data entry remains in Excel even after viewing shifts to an app, dual maintenance persists. In custom development, we bring entry, approval, and update workflows into the app, enabling organizations to graduate from spreadsheets.
The 5 phases of client support for building internal business apps to move beyond spreadsheets
Phase 1: Current state audit (1 week)
- Auditing spreadsheet operations and redundant management
- Reviewing data platform architecture, permissions, and data quality
- Identifying target workflows (inventory, orders, expenses, etc.)
- Prioritizing in-house development initiatives
Phase 2: Design (1–2 weeks)
- Designing business workflows (entry, approval, updates)
- Designing permissions and row-level security
- Structuring data models and audit requirements
- Formulating phased release plans
Phase 3: Implementation (2–4 weeks)
- Implementing business apps running adjacent to data
- Input validation and approval workflows
- Migrating data from existing spreadsheets
- Embedding permissions and audit logging
Phase 4: Adoption (1–2 weeks)
- Operational training for frontline staff
- Parallel runs and incorporating user feedback
- Phasing out spreadsheet operations
- Establishing monitoring and backup procedures
Phase 5: Ongoing operations (continuous)
- Monitoring usage metrics and data quality
- Modifications in response to operational changes
- Expanding to new business applications
- Handing over knowledge and operational runbooks
Standard technology stack set for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| Data platform | Snowflake / BigQuery, etc. | Existing DWH |
| App execution | Runtime colocated on data platform | Separate infrastructure + connectors |
| Permissions | Roles / row-level security | Re-implemented in the app layer |
| Auditing | Platform audit logs | Custom logs |
| Input UI | Forms / approval workflows | Spreadsheets (target for phase-out) |
| Visualization | Operational KPI dashboard | Manual aggregation |
Which projects need this and which do not
| Projects requiring this | Low-priority projects |
|---|---|
| Data platform already exists | Data scattered across multiple places |
| Painful duplicate management in spreadsheets | Handled on paper or verbally |
| Permissions and auditing are business requirements | Extremely small sharing scope |
| Handles inventory, orders, and expenses | One-off aggregations only |
| Entered daily by on-site staff | Input frequency is very rare |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Target scope | Operations to bring in-house | Agreement on priorities |
| Permissions & auditing | Demarcation of access control responsibilities | Audit compliance requirements |
| Data migration | Migration from existing sheets | Handling missing data and duplicates |
| Adoption | Training scope | Involving on-site staff |
| Handover | Source code / Runbooks | Maintenance framework |
| Ongoing maintenance | Modifications / Monitoring | Operating costs |
Client-side ROI estimate (assuming back-office operations)
| Item | Spreadsheet operations | In-house app | Difference |
|---|---|---|---|
| Duplicate entry | Occurs each time | Unified entry | Reduction in data entry hours |
| Data freshness | Stale the moment it is exported | Always up-to-date | Faster decision-making |
| Permission incidents | Copies get leaked | Controlled by platform | Mitigation of leak risks |
| Siloing / Person dependency | Dependent on spreadsheet power users | Turned into an app | Improved business continuity |
| Annual benefit | — | — | Reduction in data entry hours + prevention of data incidents |
Even with upfront costs, it is fully justified by reducing daily duplicate entry hours and curbing data incidents.
Five common pitfalls
Pitfall 1: Turning only views into an app while neglecting data entry
Spreadsheets will remain, and duplicate management will continue. Bring processes all the way through input and approval.
Pitfall 2: Re-implementing permissions on the application side
They will drift from platform permissions and cause incidents. Inherit roles directly from the platform.
Pitfall 3: Not verifying the quality of migrated data
You will inherit junk data and lose trust. Cleanse data before migration.
Pitfall 4: Building without involving on-site staff
The app will be left unused. Establish training and parallel operations.
Pitfall 5: Failing to keep audit logs
You will not be able to track who changed what. Enable audit logging on the platform.
90-day action plan
| Week | Action |
|---|---|
| Week 1 | Inventory of duplicate management, platforms, and target operations |
| Week 2〜3 | Business workflow + permissions design |
| Week 4〜7 | App implementation + data migration |
| Week 8〜9 | Training + parallel operations |
| Week 10〜13 | Retiring spreadsheets + launching broader rollout operations |
Conclusion — From "building dashboards" to "delivering systems running operations directly on data"
Business applications that run right next to data bridge the divide between data platforms and frontline operations. From the perspective of supporting system development through custom development, guaranteeing permissions and auditing on the platform side, accommodating everything through data entry and approvals, and integrating apps into daily operations before handover in our "In-House Business App Transition Support to Move Away from Spreadsheets" serves as our new core offering that delivers in-house applications uniting data and business operations as deliverables. If you are expanding to integrate internal tool suites, please also read Client Projects Integrating Internal SaaS with Notion Developer Platform (GH Media), and for overall DX approaches, see SME DX Success Stories (GH Media).
If you are looking to "graduate from duplicate spreadsheet management," "put data platforms to work in daily operations," or "bring development in-house while preserving robust permissions," feel free to reach out via our contact form.
Sources
- Introduction to Snowflake App Runtime — Deploying Full-Fledged Web Apps Right Next to Data with a Single Prompt! (Zenn Trending 2026-06-05)
- Custom Data Platform Design with Snowflake Agent Sharing (GH Media)
- Client Projects Integrating Internal SaaS with Notion Developer Platform (GH Media)
- 5 Selected SME DX Success Stories (GH Media)
