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."
It is a valid problem but hell it is a very attacked problem. There are thousands of staff scheduling solutions. I think "does the software work for your industry" > the algorithm used. E.g. if the vendor is proven to work for fire-fighters rosters then it is low risk for another station or brigade to adopt. It is other features like HR and payroll integration, access control, working time regulations and law, attendance recording etc. that will make a big difference.
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?
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 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."