Here's my two cents: your FTUX has so many steps and so many tour popups, and IMHO these are overwhelm your value prop. You have an opportunity to focus more on your value prop first and foremost. If you like, I can give you my actual use cases.
I use AWS, and I use multi-tenant Postgres such as with a tenant_id row, as well as multi-region setups, and for some projects one database per end organization tenant.
On AWS I use Aurora and also some self-managed Postgres. Some of the Postgres extensions I use are for geofencing, trigramming, etc. and these ideally could/should have tenant-specific instantiations. I code using Go & Rust. I work in regulated industries that use SOX, HIPAA, FERPA, etc.
Can you speak to if/how the Fortress value prop can help me, and if/how/when to get the API in Go and Rust?
We've seen most SaaS companies use some sort of tenant_id column and this is definitely the most popular method that developers currently use.
We want to provide a few things for SaaS developers. For one, many SaaS companies will face the need to create a completely new isolated database instance and may need to deploy this instance on a specific cloud (we know that Azure is really popular for healthcare).
Further, we want to spare the dev-experience of using WHERE clauses and/or setting up RLS. We aim to provide a seamless DX that abstracts over where the tenant data actually is and provide a unified platform that developers can trust to provide native isolation. We are pretty early but want to hear whether these resonate with you!
> Further, we want to spare the dev-experience of using WHERE clauses
A laudable goal, but one which is easily solved at library level, or at the "infrastructure code" level. I've been doing this across a range of databases for several years.
When talking to a specific customer, in my experience, it's better to not use phrases like "we know that many companies JUST LIKE YOU do X and Y". That seems unpersonal and frankly, a bit like a smartass.
Better:
- Reply directly to their concerns and questions without any fluff.
- Ask the customer about their problems, wants, and needs. Maximize your understanding of their problem space.
- And: Throw out the jargon. [0] It sucks.
[0] "provide a unified platform that developers can trust to provide native isolation"
We still definitely need to work on our language to best communicate this; we'll work on keeping it more concise and straightforward to best highlight what we offer.
> We still definitely need to work on our language to best communicate this; we'll work on keeping it more concise and straightforward to best highlight what we offer.
That sounds like an AT&T customer service chatbot.
Do you speak like this to other people, in day-to-day life?
> DX that abstracts over where the tenant data actually is
This goes against any of the main items that @jph closed with: COMPLIANCE.
So - abstracting the implementation complexity is difference than abstracting the "where data lives" - especially with Compliant requirements such as SOX and HIPAA, wtc. -- Its been a while but I've done some significant sized HIPAA and SOX, SAS70 and other compliance audits - and one of those reqs is "data retention for ~7 years" in many compliance laws... and so abstracting where data resides no beuno. (Surely you didnt mean that literally?)
I am currently working on am 10DLC compliant SMS routing platform... and so I get to dive back into compliance - and I know already I have to know where all my flows tick KPIs in a way I can visibly and empirically document life-of-a-data
And "Secure, Multi-tenant DB Routing as a Service." might be a better DNA for the tag-line.
--
Also, I think I recall youre previous HN announcement for the AI scraping?
But - in conjunction with this, it would be great to have a PWA-DB that is my own RLS multi-tenant for my personal data that I own all my records and companies have to subscribe to RLS access to my PII and blacklist all databrokers and scrape for who has my PII so I can actively manage who is accessing any of it - (Using both of your AI Scraper/Crawler tool and some-version of this seems like that could be a reality)
(I love what youre doing - as other HNers said, Got to get the right CorpoSpeak bolted on here for BigBanko :-)
That makes complete sense. A little correction from what David was saying: We don't want to abstract away the data stores; we want you to have complete ownership and observability of that. However, we want to make the infrastructure easy to manage, set up, and interface with. This is why we are making a big push to BYOC to allow you full data ownership. I like the direction of your tag line. Making sure that our security and privacy mission is loud and clear is important.
That is a super interesting idea. We have also been really tickled with the idea of owning our own data, and that is somewhat of the mission that drives us to make data security and privacy more accessible for developers. I love the connection to scraping.
Its important to realize just how powerful and important a good AI scraper actually is - especially one that can now route to a RLS-level-DB-Connector - whereby I can pull a scrape, then use the BYOC asa router to place my scrapes into various catergories where I am using the idea of a tenant as a bucket for information. And if I can then do views on those data-sets based on the app-straction one needs.
The example is that this can apply smart DB insertion into tables where youre using RLS as the route-ing rule that says "Any [fields of [this_type] from [urls] go [DB.schema.table.row]" and then provide views to these based on whatever presentation you want a component to view that data, like a structured form dynamically screaped into view with a RLS view rule...
(Just look at all the recent posts to HN where all these legos have basically been put up in the last 3-months.
Al Erector-Sets are currently being assembled and the amount of tool-age is mind-blowing awesome)
This prompting post on reddit was really interesting:
Here's my two cents: your FTUX has so many steps and so many tour popups, and IMHO these are overwhelm your value prop. You have an opportunity to focus more on your value prop first and foremost. If you like, I can give you my actual use cases.
I use AWS, and I use multi-tenant Postgres such as with a tenant_id row, as well as multi-region setups, and for some projects one database per end organization tenant.
On AWS I use Aurora and also some self-managed Postgres. Some of the Postgres extensions I use are for geofencing, trigramming, etc. and these ideally could/should have tenant-specific instantiations. I code using Go & Rust. I work in regulated industries that use SOX, HIPAA, FERPA, etc.
Can you speak to if/how the Fortress value prop can help me, and if/how/when to get the API in Go and Rust?