aneeshd16

I built a tool to generate a PDF for each row of a Google sheet. For example, you can generate 100 personalized PDFs (like certificates) for 100 students listed in a Google Sheet.

https://sheetstopdf.com/

Once you sign up and connect your Google sheet, it generates a template (using AI) based on your data, which you can edit in a Notion-like editor. You can then generate PDFs for your entire sheet or a for a range of rows.

Some use cases I'm seeing:

* Certificates for students or course completions

* Monthly invoices for all your clients (https://sheetstopdf.com/use-cases/business/invoices)

* Personalized reports with individual client data

* Event tickets or conference badges

* Contracts, offer letters, or any personalized documents

* Really anything where you have rows of data that need to become individual PDFs

Would love to hear what you think or if you have use cases I haven't thought of yet!

I'm building an app to help users find free and paid street parking in Vancouver: https://instaparkr.com/

While apps like Parkopedia and SpotAngels tackle the same problem, their one-size-fits-all approach often results in incomplete, missing, or outdated data. My approach is different: go deep on one city at a time by combining multiple publicly available datasets. This doesn't scale horizontally since each city has different data sources and formats, but the goal is to become the definitive parking resource for one city, build automation to keep it current, then methodically expand city by city.

If you are based in Vancouver, do give it a go. Your feedback would be awesome!

I think the key concept here is atomicity. If some API is responsible for creating a job, storing it in the database AND publishing it can never be an atomic operation. Both the database and pub/sub servers are separate network connections from the application server. For example, if you save the record first and then publish, It's quite possibe that you save the record in the database and then lose the connection to the pub/sub server when publishing. If this happens, you can never know if the pub/sub server received the request and published it. In systems where it's critical to guarantee that a record was saved and guarantee that it was published as well, the only way to do that is by using a single external connection - in this case to a Postgres DB. We've used the same setup on an AWS RDS t2.medium machine to process over 600 records/second.