We do have a single-tenant DB. That’s one of my architecture challenges- how to handle permissions and clean up the schema a bit to entities that only my users need.
Possibly achieve that with some views or w/e the equivalent is in your database, and database accounts that can only access those views.
Another option might be to let them ingest their data directly into the existing BI tools they use where they can do whatever they want, cool thing about that is it can entrench you into their infrastructure and it offloads a lot of this complexity you're dealing with.
Okay- just spent the whole day tinkering wit this:
1) I create a baseline set of views I want my customers to have
2) For each new customer, I’ll run a script that create a replica of those views- filtered by their customer ID
3) I’ll allow my customers to write pure SQL- limiting them to only SELECT queries and a couple niche business rules, as well as masking any DB-level errors, because that just feels wrong
I think the main thing you're missing is creating an account in the DB that only has access to those views, so for each customer you'd do something like:
CREATE USER customer_xyz WITH PASSWORD 'foo';
CREATE VIEW customer_xyz_data AS SELECT * FROM data_stuff WHERE customer_id=x;
GRANT SELECT ON customer_xyz_data TO customer_xyz;
So then two things are happening, SELECT-only is being enforced by the view itself no matter what, and their account is categorically unable to touch anything outside of that view too, so as long as you run their queries through that account it will always be sandboxed.
You can enforce all of that yourself but ultimately if they're using an account that can read/write other tables you will always have to be careful to make sure you are sanitizing their input not just to selecting but like, limiting joins and nested queries too.
Gotcha. Yeah- I was thinking of working with my engineers to figure out a permissions layer, but I understand enforcing that at the DB-level would guarantee security.
Dumb question- is creating a set of Views for each customer even efficient for my MySQL database? I could realistically see us having ~12 customer-facing views- is having 12*N views a smart and scalable way to architect this?
A view is just a query that pretends to be a table, so it will come down to the complexity of that query. Each time you're querying the view it will be running the combination of the user's query against the view's query so the performance comes down to whether your DB is optimized around basically "SELECT field1, field2, field3 FROM (SELECT * FROM data_stuff WHERE customer_id=x)". Whether you execute that query as a view or as ad-hoc SQL doesn't make a difference itself.
"Your side" of this can be optimized easily enough, but the user-submitted queries are likely to be inefficient or miss indexes, which is why one database per customer can be better since they each have their own resources.
You can create the views and accounts as needed and destroy them when sessions end rather than keeping them permanently too, so when the user signs in you create the view and account, after the session or some period of inactivity you remove them.
Makes sense. The fact that my SQL Editor puts tables and views in the same section on its left sidebar was the main reason I did a double-take.
The idea of deleting and recreating views is an interesting one. I see that as a really cool approach- considering we can go without it as a v1 then include it as we scale.
Thank you for all your advice so far! This has been truly helpful.
Finding a co-founder, plus making those first few hires, is easily the most challenging part. You're going to realize you can't solve every problem, and you'll need help. Finding your team is like finding a life partner- a great one that complements your strengths and weaknesses could set you up for life. The wrong one will result in mismatched effort, finger-pointing, and time spent away from the customer.
It's one thing to ask a user to give you $20/mo. It's another thing to ask another human to wake up with you every day and spend their prime working on your vision in opportunity cost of working on something else. It's going to be the most important sell of your life!
Given two Goodreads accounts, BookBlend uses a combination of web scraping, data analysis, and LLMs to calculate a blend score from 0-100. It shows you shared books, authors, and genres, as well as recommends books for the two to read together!
It's 100% free, and the source code is available on the "info" modal in the top right.
I'm the only Customer Success guy at the company. Currently onboarding ~15 customers. I come from a more technical background and not the domain of my customers.
How would you augment them to keep the high touch experience you've had?
If I had a wishlist, it would be another hire, and they would complement me by providing more domain knowledge than I do. Sometimes, Im anxious that I'm not "asking the right questions" during onboarding.
Do you need to keep that high touch experience?
Our sales team really leans into our high touch experience, because that where our competitors fall short. Recognizing that "white glove support" is a real advantage, I'm trying to figure out if I can keep that. What I guarantee is that no customers would be live without my support (not trying to sound important- it's just that we seriously have no self-service abilities). Since our customers are so nontechnical (think floor operators in healthcare), the product team furloughed self-service in exchange for my white glove services.
Have you had an engineer roll with them through onboarding to see where technical efficiency gains through software and automation could be found?
We have not done that! Our tech team is very flooded with tickets on future product creations, that it's been tough to capture their time.
I have someone I worked with in customer success at a YC unicorn I think you would get value from speaking with to build some momentum to power out of this blocker, I believe them to be a skilled practitioner in the trade and trust their guidance as it relates to this domain. I'm happy to buy you an hour of their time. Let me know if you're interested, and I'll connect you. You can get my email from the mods.
A analysis of Notion (a platform) and Linear (a point solution)... how both go about defining their brand and product decisions, and which queues my startup should take instruction from.
Along the same lines, I recommend Retool's retrospective article [0] about pipes, for some of the perspective on how it looked from inside yahoo. I'll grant that, towards the end, it is an ad for their service.
We built an entire app for our golf league- all using Glide and Google Sheets.
It was honestly a great experience- all the players had a great mobile experience with obvious forms and leaderboards, while the storage and compute was hidden inside the Google Sheet. The pricing was pretty reasonable- considering we could split the bill among us all, and we only needed it for about 4 months.
There’s still hope for good, quality SaaS! However, I hope Glide (or another) can figure out the pricing for the hobbyist tier.
Hey! My intention with this sentence is to say that although the content is publicly available, the viewer may feel like they're still "not allowed" to be watching it.
Others in the comments articulated this better than me:
> I understand that these videos were made public, but still this kinda feels like violating people’s privacy. They most likely never intended for us all to watch their personal videos a decade later.
I tried to distill it in a couple words in the blog, bc I didn't want to harp on it. In retrospect, I could've explained it better.
