You are spot on about the market saturation and the "moat" being integrations rather than just the algorithm. It is a brutal space.
I am actually building a new tool in this space (TimeClout.com) precisely because, despite those thousands of existing solutions, I saw friends running a medical unit still drowning in spreadsheets. The "proven" enterprise vendors were often too rigid or expensive for their specific needs, and the lighter tools couldn't handle complex constraints like "fairness" (e.g., ensuring everyone shares the burden of inconvenient shifts equally).
My wedge isn't just "another roster app," but focusing on the constraint solver itself—using AI to automate that complex Tetris game of qualifications, rest times, and fairness metrics that most managers do manually. I’m also betting on an open-core model (repo is at djinilabs/timeclout) because I think the logic should be transparent and hackable.
I’d be curious if you think a "better solver + open source" approach is enough to compete against the heavy HR/payroll integrators you mentioned?
This is a huge pain point—validating this problem is definitely not the hard part! I’ve been tackling the exact same "Spreadsheet Tetris" nightmare with TimeClout ( https://timeclout.com ).
We actually just open-sourced our solution because we realized that while the scheduling interface needs to be simple, the optimization logic (fairness, constraints, sales matching) is where the real complexity lives. Since you're building something similar, you might find our approach interesting—we use a constraint satisfaction AI solver to handle the heavy lifting.
We’re currently looking for beta testers to stress-test the scheduler in real-world hospitality scenarios. Since you're deep in this space, I'd love to hear your take on our approach vs. what you're building.
Best of luck with your tool—the market definitely needs more than just "digital spreadsheets."
While tRPC offers great developer experience with end-to-end type safety, GraphQL's client-side query customization provides architectural flexibility that shouldn't be overlooked. A deep dive into why GraphQL's advantages remain relevant.
How we designed and implemented a reactive, type-safe, spreadsheet-inspired language with real-time updates, dependency tracking, and incremental computation.
We built a production-ready streaming AI service using AWS Lambda, Architect, and Vercel’s AI SDK that provides real-time responses with tool execution capabilities, complete with local development environment and custom deployment workflows.
Learn how to automatically deploy every pull request to its own isolated AWS environment, complete with custom domains, SSL certificates, and full-stack infrastructure. This guide covers the architecture, CI/CD pipeline, and best practices for building robust, production-like PR deployments that supercharge your team's development workflow.
Instead of building a complex API surface for your AI agent, make it interact with your app like a human user would. Use the Accessibility Object Model (AOM) to give your agent “eyes” to see the UI and “hands” to interact with it. This approach is simpler, more maintainable, and has the bonus of making your app more accessible for screen readers.
Infrastructure, as we know, can be a challenging subject. We’ve seen a lot of movement towards serverless architectures, and for good reason. They promise to abstract away the operational burden, letting us focus more on the code that delivers value. Add Content Delivery Networks (CDNs) into the mix, especially those that let you run functions at the edge, and things start to feel pretty good. You can get your code running incredibly close to your users, reducing latency and making for a snappier experience.
But here’s where we often hit a snag: data access.
Very good points. One thing that still makes us broad but narrows down is the fact that we are focusing on financial modelling and analysis.
But yeah, as Nuno pointed out, it's a new product category and super broad in application, which is part of what makes us excited about this!
We love Observable, but Decipad is made for a different audience and use cases.
We are focusing on numbers and collaboration, while Observable kind of focuses on the programmers and the DataViz community.
The Decipad user shouldn't have to know how to program.
Observable uses JS. Decipad created a custom language with a number of specific features, like the way we handle units, dates and dimensions.
(We can also use JS if you want to).
We have and plan to creating custom widgets for specific use cases for financial and quantitive modelling and analysis.
About the richtextdetails, the CRDT is based off of Quill.js deltas (https://github.com/quilljs/delta), composed by an array of such operations.
Anyway, this is all interim work, and we plan on making this independent of any specific library by implementing a generic CRDT on top of IPFS DAG and Pubsub APIs. If you're interested you can follow / chime in here: https://github.com/ipfs/research-CRDT/issues/11
Remote pinning would work as any other node that you give the permissions to read the feed. This node would follow the CRDT changes, persisting them locally.
Each keystroke produces a change in the CRDT, which is then eventually propagated to all participating nodes.
Each CRDT message is signed and encrypted before being sent over the IPFS pubsub network.
PouchDB has great support for getting conflicts and merging them, it doesn't have to be dealt with at the sync layer.
Since the client is the owner of the PouchDB database, it has direct access to conflicts and can fix them on the spot.
Your data should be devised to be easily mergeable. Some document schemas are more easibly mergeable than others, CRDTs being the easiest extreme I know.
This can be addressed in CouchDB, by creating a validating function that validates all the incoming updates.
Besides that, I'm addressing this via the architecture (there's an aside in the article where I cover this briefly), which will be a subject of a future article:
Central records shouldn't be directly changed by a user. That's now how central record systems should work.
Instead, we should view any document as a request to get or change the central records, to be processed by a clerk. The clerk then changes the state of the document according to the permissions and results.
I am actually building a new tool in this space (TimeClout.com) precisely because, despite those thousands of existing solutions, I saw friends running a medical unit still drowning in spreadsheets. The "proven" enterprise vendors were often too rigid or expensive for their specific needs, and the lighter tools couldn't handle complex constraints like "fairness" (e.g., ensuring everyone shares the burden of inconvenient shifts equally).
My wedge isn't just "another roster app," but focusing on the constraint solver itself—using AI to automate that complex Tetris game of qualifications, rest times, and fairness metrics that most managers do manually. I’m also betting on an open-core model (repo is at djinilabs/timeclout) because I think the logic should be transparent and hackable.
I’d be curious if you think a "better solver + open source" approach is enough to compete against the heavy HR/payroll integrators you mentioned?