No real comment on the idea itself, but will comment on the site itself.

I'm on a decently specced laptop (32GB RAM, 5GHz CPU), and this website is performing horribly. Scroll feels janky, things run at low fps and generally doesn't feel very snappy. Not great for something that seemingly has no animated/media heavy parts?

I looked at the tab in my about:processes on firefox and it's using between 300 and 500 MB of RAM. There is absolutely no functionality on this site that needs that many resources. Flutter is hindering you here. It's useful if you're converting a mobile app to web, but for this website it's making for a terrible experience. You'd be better served by a web-first tool.

What's the risk either way?

In other words, do you even need other people to tell you yes or no to this, or could you just do it in a day, put a sales page up, and validate the idea directly already? What do you lose other than a bit of time?

Thanks for the insightful reply as always Cat! Will reply on points individually.

1. Agreed, I've also made better connections directly and through events I host myself in the tech community.

2. In the current tech downmarket those sorts of boards have been less active, but yeah, I have heavy presence on a local Slack tech community and have built a network there. So the job board is useful, when people eventually get back to posting relevant freelance gigs. Great idea on being sneaky with looking at competitors!

3. 100%. Ironically despite moving outside of Cape Town, I spend more time in industry events in CPT than ever before. I also host a niche tech community meetup. Maybe the calm town vibes are giving me more rest and energy to go out! So I have been wondering if just going full tilt and attending more of those events (and hosting more with the community) makes more sense than this sort of accidental split strategy I've had.

The main drawback I think is that networking like that will anchor me more to my locale - as someone with longer term plans of emigrating and travelling, I'm not 100% sure if that's a smart move. But then again that's also why I'm on WIP too - wanting to build my own SaaS for that independent income so I can do what I want globally anyway :)

Agree on setting boundaries - think this is also part of my problem. I have a bit of an addictive personality, so I tend to make a habit of checking Twitter and LinkedIn too often.

Thanks for reminding me of your Substack, need to go subscribe. Glad to hear it's not just me feeling this way though!

I'm a bit saturated on communities and groups for a while though thanks 😅 Though will go lurk on Superpath a bit

I've done migrations between providers before, but not specifically LS to Stripe/Paddle. I did Mangopay to Stripe.

You at best will be able to transfer customer details, but you will not be able to transfer any saved payment data between providers, so all your customers will need to re-enter their details to remain subscribed.

It's a regulatory restriction with KYC/anti money laundering regulations and PCI DSS compliance for the payment providers.

In order to do this successfully you will need to run both providers at the same time. The smoothest way will be to have all new customers use the new provider, and prompt existing customers to the new provider with both a notification ahead of time and when their subscription needs to renew.

LS or Paddle, because I don't have a choice. Stripe doesn't operate in South Africa and there are 0 payment providers here offering charging in USD. Big potential conversion issue.

Price wise you're going to pay similarly with any MoR, so LS and Paddle are basically no different.

If your aim is to learn new things specifically for shipping, then yes.

With only the free packages in the official ecosystem, you can have user registration & auth, payment provider setup (Stripe, Paddle, or LemonSqueezy), application performance monitoring, feature flags, code quality linting, websockets, API setup (both simple and complex like OAuth) and social logins (e.g. Google), all running within a few minutes.

Then there's the free WAMP/XAMP alternative called Herd which makes the dev environment easier.

Then there's the paid ecosystem, which can take care of infrastructure for you (both normal servers with Forge and serverless with Vapor), deployment (Envoyer), have premium payment dashboards (Spark), and application admin panels (Nova, but I prefer the free Filament instead)

You don't have to use the ORM if you don't want to. But that's really like 5% of the framework when we're talking about using frameworks.

Personally ORMs just make things faster to develop with than hand writing queries.

There's also plenty of learning resources online, like Laracasts.

There are projects out there scaling pretty well with just SQLite, there's no reason yours wouldn't. I wouldn't worry about trying to serve 1 million a month yet if you aren't even serving 1. Solve problems as they arise, not before.

Oh and PS to optimise your SQLite DB performance, have a look here:
github.com/nikspyratos/toybox…
All of those are pulled from this and other articles:
kerkour.com/sqlite-for-servers

The long and short of the multi-db usage as well is that there's separate databases for Queue, Cache, and Pulse (performance monitoring) functionality, because each of those can become very write-heavy and affect users as app traffic scales up.

Welcome back, and hell yeah welcome to PHP!

Yeah, this is really not a good idea unless you have a very specific technical reason for it. Pieter Levels does it for his projects, but I'd focus on taking product/business advice from him instead of technical advice most of the time.

One of SQLite's limitations is only having one write connection to a database at a time. So splitting into multiple different DBs allows you to have multiple write connections. However, for most projects, it's unlikely you'll hit a traffic scale where you would need to do this.

What I would recommend doing this for is when you have app functionality that can be DB-heavy and you don't want to affect your users, like a DB-drive cache or queue system.

If you aren't using a framework yet, I can highly stress that you try one out. And especially if that one is Laravel! If you think base PHP is fast to work with, once you get the hang of the ecosystem, you can go to super speed with Laravel.

If you'd like an example of this multi-SQlite DB pattern, I use it in my #toyboxforlaravel project.