Particularly in the AI assisted era, I'm not sure I understand why you wouldn't just roll your own auth. Learn it once, use it everywhere. Best practices are well documented and now incredibly accessible via your LLM of choice.
You wouldn't just blindly implement what the LLM generates. You would use it more as an efficient way to go through all the necessary docs. From there you'd sanity check the recommendations and _then_ implement a solution, applying your judgment along the way.
My bet is on Remix (which will eventually just be React Router). I think it's just the right amount of abstraction over native web functionality with a nice, simple API that doesn't deviate too much from web standards. I also think the full stack approach just makes sense for developing on the web.
Remix is backed by Shopify, compared to Next.js being backed by Vercel. Does this influence any decision to take?
Today Next.js has a big advantage which is that they have already integrated most of the new React 19 rendering features and apis. I think it will take a while for Remix to catch up to that.
Other notable frameworks are community led Waku made by Daishi Kato from Pmdrs and TanStart made by Tanner from Tanstack.
Also there's Redwood.js betting on a more integrated experience.
Today I am using Nextjs because I don't think I can go back to not using RSCs, but when Remix catches up or Waku and TanStart get to v1, I sure will give them a serious try!
Shopify "backing it" means less to me than the maintainers themselves. The Remix maintainers are straight shooters and have been maintaining open source consistently for over a decade now.
how strongly do you believe this. because ive just read both docs and i think they have different goals/audiences (tho obviously same owner). i think react router will be a poorer project if it starts to require serverside components like it is looking
They made an announcement that they are merging the projects a little while back: https://remix.run/blog/merging-remix-and-react-router. Obviously things could change, but I think RR v7 will effectively be the next iteration of Remix.
Honestly, I hated Prisma for the longest time. Like, hated it. I tried to rip it out of projects multiple times. Why would you build a node library in Rust? (as one of many problems) But, I had a mental shift recently that helped me appreciate it more: I use Prisma only for features that fit neatly into an simple ORM (i.e. building a web page based on a bunch of joins). Anything else, I use raw SQL.
- If I want derived data, write views that encapsulate the transform. Prisma supports reading from views
- If I need something more complex, use DuckDB + python for analysis and write to the appropriate table.
- If I need to cache complex queries, just use a materialized view and read it as a prisma object
It's not perfect, but that let's me use prisma for what it's good at (Managing an ORM and deeply nested queries), then fall back into raw SQL for everything else.
Going straight to SQL has been a breath of fresh air, but, let's be honest, dealing with deeply nested joins really sucks when all you want to do is build a page that shows a company, all of it's people, and all of those people's relationships. ORMs are pretty handy for that last case, and I use SQL for everything else
I've looked into it a bit. I'm getting to the point where I either want to use a full ORM, or I want to write raw SQL and have it checked against the database.
Query builders are nice, but they sometimes end up in this middle ground where they have the worst parts of an ORM (needing to learn a new syntax and not getting access to all the DB features) and the worst parts of raw SQL (Unpacking relationships into objects w/ pointers is error prone boilerplate that sucks to write).
I love SqlAlchemy since it's still enough of an ORM to solve the main problem I want solved. Super curious to hear if you've had good experiences with Keysley and how it deals with transforming relationships into objects
Interesting. I think you're on to something here. I fully agree that a combination of spreadsheets and SQL are the ideal tools for data analysis -- not a SaaS GUI.
> Niching down, if you work in operations at a <50 person startup or SMB and your company relies on a Postgres or MySQL database, Sourcetable is an affordable reporting tool with turnkey data infrastructure that doesn’t require code or engineers to set up.
With the rise of AI, companies like Tembo that help you set up all in one databases, and tools like this, I'm increasingly of the mind that many companies should start bringing things like analytics and observability in-house. I don't see the need to pay Mixpanel or Datadog thousands of dollars per month when a self-serve solution that relies on tried and true tech is more or less at your fingertips.
Minus the AI part tools like this have existed for decades.
And companies are not dumping their SaaS tools and switching to them en masse.
Because (a) data silos have dramatically increased pushing dreams of a unified data schema out of reach, (b) technology stacks have become far more complex necessitating tools like Datadog and (c) competition is stronger than ever meaning that skimping on paying for tools like MixPanel is often short sighted and counter productive.
Companies like this will do fine and there will be always be a demand for them especially in the SMB space. But there simply isn't the business value in bringing a lot of analytics and observability in-house in almost all cases.
Not yet. But in the analytics case, suppose you could build a tool that collected data on your own infrastructure, allowed you to write plain SQL against a PostgreSQL database to get whatever analytics data you need, had an AI-driven text-to-SQL option so non-technical users could get whatever analytics data _they_ need, and output everything to a universal interface, i.e. a spreadsheet? No vendor flavored DSL, GUI, or workflows to learn. That product would be tough to beat. It wasn't built in the past because it was hard. But with AI and something like Tembo or Timescale, is it actually hard anymore?
Agree. A general thesis I have is that the API-ification of the web fragmented business information, and with every new SaaS tool we fragment our company's data further. The trend at all company sizes is to be increasingly analytical, but for SMBs it's too hard to get access to your data (mainly due to technical limitations). So it makes sense to centralize data somewhere, and we think that somewhere is inside the data tool that everyone actually uses: the spreadsheet.
Many other advantages of this data centralization too. Data + spreadsheets + compute is a nice application base for agents.
There is a separate answer here which is many (most?) SMBs can't afford technical folk, so the ability integrate data at all, talk to it and model it (using SQL or AI), is already a big step forward for them.
My personal use case tends to involve a lot of Postgres data and transaction events for my reporting. We see "simple" businesses like parts manufacturers, print shops, vineyards, etc. all doing something similar.
Yes some integrations are excellent (hey Stripe : ), some are terrible (no comment on who). We're finding that LLMs increasingly able to fill the gap around organizing data schema for that initial data prep piece where someone has to build the data tables that others consume. To your specific question/problem set, when a schema updates you end up with a "fuzzy schema matching problem"; we are solving that separately anyways for a separate product feature requirement.
Strong note here that the current state of technology is much better for SMB scale data and not enterprise scale data with messy schemas.
The workflow I'm trending towards is a design system (e.g. Radix UI) for the bulk of the styling, inline styles for most customizations (shouldn't be too many), and then plain CSS with classes on occasion (e.g. I have an override I need to use in multiple places or an animation). The little CSS you do need can be isolated if you're using a framework like Remix.
As others have said, LLMs still require engineers to produce quality output. LLMs do, however, make those engineers that use them much more productive. If this trend continues, I could see a scenario where an individual engineer could build a customized version of, say, Salesforce in a month or two. If that happens, you could make a solid case that companies paying $1mm+ per year for 12 different SaaS tools should just bring that in house. The upshot is you may still be writing software, but instead of building SaaS at Salesforce, you'll be working for their former customers or maybe as some sort of contractor.
Point of sale, on iPad, in ~2011. Massively differentiated from Square / VC competitor land via doing a bunch of restaurant specific stuff early.
Trick with the $1M number is a site license was $999 and receipt printers were sold ~at cost, for $300. 1_000_000 / ((2 x 300) + 1000) ~= 500 customers.
Now I'm doing an "AI client", well-designed app, choose your provider, make and share workflows with LLMs/search/etc.
I work for a YC company in the industrial maintenance space and we've been looking at integrating machine data drive and automate certain maintenance workflows. The most difficult aspects of integrating machine data have been (i) networking and (ii) translating whatever protocol (Ehternet/IP, Profinet, Modbus, etc.) the machine's control system uses into familiar formats. In many cases, PLCs aren't connected to a network, the customer doesn't know which tags point to the data they need, IT has concerns about security, and the list goes on. How are you guys thinking about these networking and protocol translation issues?
Second question. The main platform in this space is Ignition. Do you consider yourself a competitor to Ignition or are you aiming for a different use case?
1. Since we have several customers in Aerospace who adhere to ITAR regulations, all our software is hosted on-prem so that we have no connection to the data they're using. The data in the DB can always also be taken out if a system switch is desired. Agree about the large assortment of issues that come up when integrating these kinds of systems. It would be naive of us to try to address all these all at once. We tried to make it easy to integrate our systems so that we can run pilots that start small (1 test stand, 1 bench, etc.) to demonstrate initial & immediate value and then expand from there. We want our product to grow with our users - incorporating support for new protocols as they need that become broadly applicable.
2. We see a lot of value in providing essentially a universal adapter to these protocols and hardware interfaces. Decoupling the data communication/device infrastructure from the control and acquisition workflows is big for us and this seems essential to that. A big endeavor on its own, but our existing integrations have been really helpful to our users and as it matures, we intend to continue expanding these integrations!
Hopefully 1 & 2 address your first question!
3. Addressing the second question: We've mostly been focusing on the test & operations use cases (e.g. running real-time control and data acquisition for engine tests). We see a lot of ways we can eventually service industrial controls/automation space - similar to Ignition. However, we are also aware of many reasons people in this space will want to stick to tried and true tools with a larger community and ecosystem.
We're still figuring out how we fit into that space + communicate our ability to provide the breadth of functionality and support them. Posts like this and the users who already see the value and are willing to try something more novel and developmental like us have been huge in progressing towards this.
Some questions I have!
1. What parts of the networking have been most challenging work you wish could have already been done for you?
2. For interfacing with protocols - similar question as above but also which ones were pretty nice to work with and what about them made it so? Closely related which direct integration would you immediately want if you were considering something like Synnax?
3. Related to the customer not knowing the mapping of tags to data - are there similar issues that you've experienced that make it hard to use these systems?
Ended up being a long message but I appreciate your insights on any of what I just said!
Oh, ok, the test and operations case makes sense. As for your questions:
1. It's basic networking tasks such as running a network drop, assigning IPs, making sure the PLCs are on the right subnet, etc. In many cases the PLCs aren't on a network at all and the IT team doesn't really know how to work with the PLCs and the OT team doesn't really know how to work with networks. Sometimes it's been easier to just add external sensors and go over a cellular network and skip the PLC altogether.
2. We use one of Ignition's modules to interface with the control systems directly. They have drivers for Allen-Bradley, Siemens S7, Omron, Modbus, and a few others. The downside is Ignition doesn't have an API, so we have to configure things using a GUI. Beyond Ignition, the other big provider of drivers is Kepware - they probably have a driver for everything, but again, they aren't really set up for use by developers trying to deploy to a Linux box. If the customer has an OPC-UA server set up, we can connect to that using an open source library.
3. What we've learned is that many customers rely on third parties (e.g. the machine manufacturer or a system integrator) to configure their system, so when it comes to extracting the data they want, you're kind of on your own. We're not industrial system experts, so this creates a unique challenge. Larger and more sophisticated customers will have a much deeper understanding of their systems, but these folks are usually going to be using something like Ignition and will already have the dashboards and reports so it's more a matter of integrating with Ignition.
LemonSqueezy itself or Paddle. Both are merchants of records. At least paddle (maybe LS too) allows reverse invoice which is important for some home grown startup saas as they simplify taxes to single customer (paddle), one invoice and one tax jurisdiction usually.
This is great. I find I'm using Figma in place of other tools more and more. I could see using Figma instead of Word / Google docs pretty soon as well.
