Data table: After 10,000 rows
Every year, the average worker loses $4,300 fixing spreadsheet errors. Not from bad decisions or market shifts. From a text field that accepted the wrong input. A copy-paste that went one row too far. A filter that nobody remembered to reset.
Data tables are where work actually happens. And almost nobody has designed one that takes that seriously.
Problem
CRM users don't visit data tables. They live in them. Research shows 33% of sales teams spend 3 to 5 hours per week inside table views. 24% spend over 10 hours. For many, it's the first thing they open in the morning and the last thing they close at night.
And yet most data tables were designed like they're a secondary feature. Something functional, not something people actually have to use for hours at a stretch.
The cost shows up in the numbers. 94% of business spreadsheets contain errors. Not occasionally, consistently. The average worker spends 3.6 hours per week correcting mistakes that a better-designed table could have prevented. That's $4,300 per worker per year, gone. Not from bad strategy. From a field that accepted the wrong input.
The deeper problem is a market split that nobody has fixed. Technical libraries like AG Grid and MUI DataGrid give you performance — they can handle 100,000 rows. But the UX is rigid, configuration-heavy, and painful for non-technical users. No-code platforms like Notion and Airtable give you intuitive filtering, collaboration, and inline editing. But they fall apart at scale.
Teams are forced to choose between fast and ugly or beautiful and slow. Nobody built the third option.
Competitive Landscape
Every existing solution falls into one of two camps. Technical libraries built for developers — powerful, performant, impossible to love. No-code platforms built for humans — intuitive, collaborative, slow at scale.
The pattern is consistent across every tool. The better the UX, the worse the performance. The better the performance, the worse the UX. Not a coincidence — these tools were built for different people with different priorities.
None of them were built for a CRM user who needs both.
The Gap
After mapping every major solution, the same five problems kept appearing. Not edge cases. Consistent, documented failures that every tool shared in some form.
State persistence. Most technical libraries save column widths and view preferences to localStorage only. Switch devices, open a new browser, join a new team — your configuration is gone. There is no team-wide default, no role-based view, no shared starting point
Filtering logic. Basic column filters exist everywhere. But nested AND/OR logic, saved filter presets, filters shared across a team — these exist only in no-code platforms that can't handle real data volumes.
Bulk operation undo. Single-cell undo works. Delete 50 rows, change the status of 100 records — and there is no way back. Every technical library treats bulk operations as irreversible.
Real-time collaboration. AG Grid, TanStack, MUI — none have built-in collaboration. No presence indicators, no conflict resolution, no activity history. Features users expect in 2025 simply don't exist.
Performance at scale. MUI DataGrid degrades visibly at 10,000 rows. AG Grid handles more but struggles with frequent real-time updates. The ceiling is always lower than real-world needs.
These aren't feature requests. They are the reasons people build spreadsheets instead of using the tools built to replace them.
Design Decisions
Every decision started from the same question. What would a CRM user actually need after three hours in this table?
Filtering that thinks like a human
Most table filters work column by column. One condition at a time, one layer deep. That works for simple queries. It breaks the moment real work starts — show me all leads from Georgia, assigned to my team, created this month, where the deal value is over 10,000 and the status is not closed.
The filter builder was designed around nested AND/OR logic. Any condition can become a group. Any group can be nested inside another. The visual structure mirrors the actual logic so users can read their own filter without translating it.
Saved filter presets were not optional. A CRM user running the same query every morning should never have to rebuild it. Presets are saved per user and shareable across the team.
State that remembers you
Column widths, column order, visibility, applied filters, sort direction. In most tables this lives in localStorage and disappears the moment you switch devices or clear your browser.
Every view preference is persisted to the backend. Not just for individuals — teams can set shared default views, and admins can define role-based layouts that new users inherit automatically. No configuration required on day one.
Bulk actions with a way back
Selecting 50 rows and changing their status should feel safe, not terrifying. The biggest missing feature across every technical library was transaction-based undo for bulk operations.
Every bulk action — status change, deletion, assignment, export — is treated as a single reversible transaction. One undo reverses all of it. The action bar appears on selection and disappears cleanly when dismissed.
Inline editing that stays out of the way
Click once to select. Click again to edit. Tab moves to the next editable cell. Escape cancels. Enter saves. No modal, no sidebar, no page reload.
The editing state is visually minimal — a subtle border change, nothing more. The data is always the focus, not the editing chrome around it.
Performance that doesn't ask you to care
Users should never think about how many rows are in their table. Virtual scrolling renders only what is visible. Sorting and filtering run in background threads. Search is debounced so every keystroke doesn't trigger a full re-render.
The target was simple. 10,000 rows should feel like 100. Scrolling should stay at 60fps. Filtering should return results in under 300ms.
Goals & Success Metrics
A concept without measurable targets is just speculation. These are the specific criteria that would define success for this table in a real production environment.
Performance Filter queries return results in under 300ms for single conditions, under 800ms for complex nested logic. Sorting 10,000 rows completes in under 500ms. Scroll performance maintains 60fps regardless of dataset size. Inline editing responds in under 100ms from click to editable state.
Error reduction Data validation at cell level prevents the 18 to 40% of manual entry errors that current solutions allow through. Bulk operation undo eliminates the irreversible mistake problem that affects every technical library today.
Time saved Filter presets reduce repeated query setup to zero. Keyboard-first navigation cuts mode-switching between mouse and keyboard for power users. Backend state persistence means zero configuration time when switching devices or onboarding new team members.
Adoption signal The real measure of a data table is whether people stop building spreadsheets to work around it. A table that handles filtering, collaboration, and performance at scale removes the primary reasons teams abandon CRM tools for Excel.
If users stop exporting to spreadsheets, the table is working.
Takeaways
Data tables are one of the most underestimated surfaces in product design. Everyone notices a bad dashboard. Nobody talks about the table they spend three hours in every day until it breaks in a way that costs real money.
The research made one thing clear. The problem was never technical capability. AG Grid can handle 100,000 rows. The problem was that nobody prioritized the person sitting inside that table for hours at a stretch. Performance and UX were treated as separate concerns belonging to separate tools.
The hardest part of this project was not designing the filtering logic or the bulk action system. It was resisting the urge to add more. Every gap in the research felt like a feature to build. The discipline was in choosing which five problems to solve completely rather than which fifteen to solve partially.
If I were to continue this project, real-time collaboration would be the next priority. Presence indicators, cell-level locking, activity history — these are the features that transform a personal productivity tool into a team one. The research is there. The design direction is clear. It needs time and a real engineering partner to do it properly.
One thing I would do differently. I would put a real CRM user in front of the filter builder earlier. Logic that makes sense on a canvas does not always make sense to someone who just needs to find their overdue leads before a Monday standup.