pgte

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."

Why your mental model of dates is broken, how programming languages gaslight us about time, and how Decipad’s interval-based approach fixes it.

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 are currently working on interactive embeddable documents, so expect some news on that front :)

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.

Hi Mark,

Thanks for your interest!

Off the CRDT libraries we analysed, Y.js was the one we picked up as it very modular, so that we could create our own connector and database layer.

These are all open-source: https://github.com/ipfs-shipyard/y-ipfs-connector and the encryption layer wrapping the database adaptor: https://github.com/pgte/y-indexeddb-encrypted/tree/encrypted

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.

This protocol is not IPFS-specific, but there are plans to change this: https://github.com/ipfs-shipyard/peerpad/issues/107

The snapshotting occurs over IPFS, producing a static and encrypted self-contained snapshot, published over IPFS.

It is possible to access the CRDT properties inside the core library, where the CRDT is formed: https://github.com/ipfs-shipyard/peerpad-core/blob/master/sr... . This could be exposed if you would require it..

If you don't mind me asking, what browser and version did you use?

It uses WebRTC for peer-to-peer communication, which is yet unsupported / untested in some browsers.

To answer your question: The collaborative data is saved locally by every participating peer.

There are plans to add remote tracking and pinning, increasing the persistence and availability guarantees: https://github.com/ipfs-shipyard/peerpad/issues/90

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.

For the client there's only one source of truth: the Redux store.

The PouchDB store is a side effect of changes to the Redux store, no need for the client to worry about these.

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.

No, you can't, tinypay uses only Paypal...

Some are corrected, and it's being proof-read at the moment. Will update every buyer once the corrected version is out :)

Thanks! :-D

I don't mind and I appreciate it, any feedback for improving it is very welcome! :-)

Thanks for the feedback, appreciated! All corrected on the new version. Will get it proofread soon, now that it got more popular :)

Loved the interview, very interesting, perfectly clear. Helped me a lot to understand the internals. Specially interested about the replication explanation. Great work, Salvatore!

I'm using CakePHP's ORM.