Seeing this, the advice: "do one thing really well" comes to mind.
Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
171–180 of 269 posts
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#172Single biggest thing you need to nail down fast: the data model. It is extremely hard to shift as things grow, and without careful thought, it’ll turn into a horrifying miasma of JSONB columns, duplicated data, orphaned rows, and garbage performance. Customers are going to store surprisingly large items in Docs, where you’d be tempted to inline them instead of offloading to S3 et al. Chat practically needs to be its…
Notion might have written something about their journey in this regard?
They have [0] [1], yes, but they also mention [2] learning that skipping building indices during a DB copy (doing so instead after the new instance is built) is much faster, which is pretty basic RDBMS knowledge. It’s great to be learning, and even better to be sharing that knowledge, but it gives me pause about accepting much of what they’ve written as expertise.
IME, many SaaS companies have eschewed the idea of having any DB experts, and this inevitably leads to pain down the road.
[0]: https://www.notion.so/blog/data-model-behind-notion
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#173There seems to be no way to delete my account..
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#174Single biggest thing you need to nail down fast: the data model. It is extremely hard to shift as things grow, and without careful thought, it’ll turn into a horrifying miasma of JSONB columns, duplicated data, orphaned rows, and garbage performance. Customers are going to store surprisingly large items in Docs, where you’d be tempted to inline them instead of offloading to S3 et al. Chat practically needs to be its…
No one cares about that. Export to open document format or microsoft. You are living in a bubble of “hackers”. You are not your average user. Case in point of “engineers are not product people”
He's actually dead on point.
Back in the day, here is Sokovia, there was a local competetitor to Facebook. They had a great start and everything went perfect for them, but it quickly turned out that the technical side was really bad. Sluggish interface, constant outages, etc.
They tried to rewrite the app from scratch two times, and eventually failed.
So yes, making sure you're moving in the right direction at the beginning of your journey is pretty important. You don't have to overengineer and stay in your shed until you have a complete, feature complete product, but at least make sure, that you're building on the right foundation.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#175This seems like the logical direction to go. Many of these apps have to be opened up to each other -- they are "modules" in a system that each company has to cobble together -- because integration is part of how any work gets done with them. The effect is a sprawling and uncertain security and access story. Hopefully Nino can bring some harmony to all this. The simplicity of the end-to-end story -- from authoring to collaboration to content delivery -- is amazing.
One thing I wonder about, though, is the effect on the engines of innovation. Something that works well about the current system -- where chat, spreadsheets, &c, are all disaggregated from each other and we have a big mess of access click-throughs -- is that many different firms can enter the space and bring new energy and ideas to these problems. Say all the apps were consolidated from the get-go -- would we ever have gotten the amazing profusion of capabilities we have now? I imagine a boot stamping on a human face -- forever.
Even when the new generation of knowledge worker apps integrate plugins, they don't seem to integrate them in a way that is amenable to commercial enterprises. For example, Obsidian does not have paid plugins, to the best of my knowledge. Without the commercial incentive, how far can that really go?
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#176Earlier quoted context omitted.
No one cares about that. Export to open document format or microsoft. You are living in a bubble of “hackers”. You are not your average user. Case in point of “engineers are not product people”
He's actually dead on point. Back in the day, here is Sokovia, there was a local competetitor to Facebook. They had a great start and everything went perfect for them, but it quickly turned out that the technical side was really bad. Sluggish interface, constant outages, etc. They tried to rewrite the app from scratch two times, and eventually failed. So yes, making sure you're moving in the right direction at the be…
This is actually the same reason Friendster failed in the face of Facebook, pun intended. Friendster simply could not keep up technically and had to shut down. Later, Facebook actually had a more solid technical footing and could scale quickly.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#177Clicked link above. Went to site that pointed to me iOS app. Downloaded. Tried to sign in, but I have to register. It sent me an email verification link, which I clicked. Got to a web page that had a button to open the app again. Which I did. And was taken back to the sign in/sign up form. Can't get past that.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#178Earlier quoted context omitted.
No one cares about that. Export to open document format or microsoft. You are living in a bubble of “hackers”. You are not your average user. Case in point of “engineers are not product people”
He's actually dead on point. Back in the day, here is Sokovia, there was a local competetitor to Facebook. They had a great start and everything went perfect for them, but it quickly turned out that the technical side was really bad. Sluggish interface, constant outages, etc. They tried to rewrite the app from scratch two times, and eventually failed. So yes, making sure you're moving in the right direction at the be…
By all means, don’t spend forever agonizing over the perfect schema and never ship. It really does not matter at small scale anyway, DBs are absurdly fast.
Just understand and accept that you are taking on heavy technical debt that will need to be repaid, and that it’s much more difficult to do once you’ve already vertically scaled several times along the way.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#179Single biggest thing you need to nail down fast: the data model. It is extremely hard to shift as things grow, and without careful thought, it’ll turn into a horrifying miasma of JSONB columns, duplicated data, orphaned rows, and garbage performance. Customers are going to store surprisingly large items in Docs, where you’d be tempted to inline them instead of offloading to S3 et al. Chat practically needs to be its…
No one cares about that. Export to open document format or microsoft. You are living in a bubble of “hackers”. You are not your average user. Case in point of “engineers are not product people”
Different apps have different technical problems that can be an enabler or a source of never-ending technical debt. Being able to add new features easily, rather than being stuck scaling, could make or break this product.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#180Single biggest thing you need to nail down fast: the data model. It is extremely hard to shift as things grow, and without careful thought, it’ll turn into a horrifying miasma of JSONB columns, duplicated data, orphaned rows, and garbage performance. Customers are going to store surprisingly large items in Docs, where you’d be tempted to inline them instead of offloading to S3 et al. Chat practically needs to be its…
Single biggest technical thing, anyway. IMO, the single biggest thing is focus and clarity in their communication. If people without a working mental model of software development can’t instantly understand the tangible problem it solves in their existing business process, they won’t even scroll past the break, let alone pay for it. Consolidation and modularity are solutions, but people don’t go shopping for solutions without a problem. Have you ever gone out looking for a better commercial version of work-related software you didn’t have any problem with? “App chaos” is way too abstract of a problem for most people to grasp. Do people have trouble sharing google docs over slack? Do companies have trouble with sharepoint and teams not being integrated enough? Does your tool do it better? Does your tool do it approximately as well, but cheaper? More reliably? If so, do people find the existing solutions too pricy or unreliable, or does that not impact them enough to care?
Unless they define, upfront, specific problems people really have, that their unified solution solves, then nobody is going to pay attention.
The second biggest problem is having an interface design team that makes all of those disparate apps consistent enough to be more usable than individual solutions. The fact that nearly no popular user-facing applications are developer-managed FOSS (as opposed to Firefox/blender/signal/et al which are managed by a company that hires professional designers) despite being free, tells you everything you need to know about dev-driven UI/UX. This is coming from someone that worked as a full time developer for years and contributed many thousands of hours of coding to FOSS projects before switching to design.