New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Sounds good to me, we will have a FULL API on launch and we will be able to integrate anything into our system too.
Thanks for letting me know, we will have a Partner API, so you'll be able to signup your clients via your API key and they'll be given an account. We can work with hosting companies to build their own package and you'll be able to charge your clients for the service.
We've used PHP/Laravel, one single code base with Multi-tenant MariaDBs. We use the base Laravel libraries and the rest have been built by our team. A formal code review will be completed before launching. But our devs do test the code to, as we like to make sure everything is good.
We will, of course, tell everyone our progress on this before we launch.
We will only send an email once we are ready for the beta testing, but thank you for signing up.
We won't be launching with a self-hosted version, we are focusing on our hosted version for now. But we might change this later on.
-10 hipster points. You're supposed to be using Rust, Ruby, and R.
-10 hipster points. You must use a NoSQL database created in the last five years, even if you need 3x the number of nodes and processors to scale it.
Of course, these are balanced out by all the "however, it works and it's easy to maintain because we used the logical tools for the job" points.
That's good news! "hipster points" are about the last thing one should be interested in when developing sensitive software. Besides, I doubt that Ruby is much more safe than PHP and rust, oh well ...
Seriously though, Ada or Ocaml would be good choices at least for the backend.
Yay, preferably one in Java ...
On a more serious note, I tend to consider any of the mysql thingies a nono in sensitive projects.
But I'll leave it at that because I really like @Jord and I want him to be successful with his project. If acting responsibly and sensibly and with plenty experience one probably can create something acceptable using the tools he/they chose. And hey, why should they be more concerned about security than the PCI people...
(and now I deduct 100 hipster points from myself, ending even deeper in the negative but I'll dance the word "tiobe")
Thank you for the kinds words
We use Galera cluster too, so we've built a nice little system to make sure we are always available.
Shudders PCI people scare me
I'm still in minus hipster points then, looks like I'll be there for some time haha.
maybe you should add more plan, like $2 for 25 active clients?
Is your total markup for all your 25 clients is $2?
I would greatly appreciate a self-hosted option. I want the flexibility.
We wanted to build something different, so that is why we went in the direction of SaaS. There are many self-hosted options out there and we are not here to directly compete with them. But rather, build a future proof system.
I think it's not about free/paid what he meant was that this software was developed by a hosting company and it's also hosted remotely by this provider and the billing system contains all data of every single customer so... and self-hosted doesn't mean free btw
"Cloud Hosted & Full SSL"
Clearly SaaS isn't a good thing for hosting/cloud providers.
@Jord Platform looks great! I was going about your website and I noticed these 2 links go directly to the IP address of the server instead of the domain name
https://i.gyazo.com/68581a258f495d384d30e7229cfb638e.png
Those are both on the homepage.
I've never used Rust and didn't spend more than 10 minutes on Ruby before I went back to Perl and Python. I have used R, which as a DSL has some great capabilities.
Never used Ada but I think it would be fun to learn. Then again, I think COBOL would be fun to learn and actually have a book on it that I read from now and then before bed.
So for multi-user relational databases (by this I mean not sqlite) you have a couple big decisions. Are you going to go proprietary? (Oracle, DB/2, SQL Server, etc.) In this case, no. That leaves official MySQL, MariaDB, and Postgres, as well as some much less common ones like Firebird. Let's leave official MySQL to the side because last I checked it didn't really offer anything that MariaDB doesn't.
So it's either MariaDB or Postgres. I think Pg is a better solution because it's always been about correctness and standards, while the MySQL family for years was completely appalling to DB pros...they made some truly embarrassing statements about how you didn't need ACID, etc. back in the 3.x days. They didn't even have foreign keys then! They're much better now but I still view them as chastised juveniles.
As for which one is more secure...I'd lean to Pg just because it's been under adult supervision longer. But I really have no idea.
I'll politely refrain from stating my opinion on Rust and Perl. Python is a nice language for quick jobs but it's no more secure than the other prominent scripting languages and has become quite fat. R I don't know well enough to comment on.I personally use Lua for scripting and in case you are interested have a look at "Terra"; quite a nice tool.
Ada is a bit harder to master than most commonly used languages but it offers a lot too, especially safety and quite elegant multi-tasking.Plus it's much less cumbersome and complicated than e.g. ATS or C plus Frama.
For me MySQL and its offspring are still appalling and I fail to see a use case where another (free) SQL DB wouldn't be a better choice. And yes, some of their designers(developers earlier statement clearly told me to simply ignore them.
Fully agree. PG is the serious developers SQL DB of choice.
Side notes: I actually like firebird for some jobs, it's a nice DB but not in the league of PG. What amazes me again and again is the NoSQL hype (and yes, frankly, I see it as little more than hype). If SQL is not needed there are still quite a few "old school" (but time tested and solid - and fast) options but I guess they are not considered as "cool" (albeit often superior). And a few of them are really fast (e.g. lmdb).
I would suggest sticking with username and not using email for login. Companies get bought, re-branding, changing admin addresses, etc.
I see that your company email is on GSuite - you are a man of culture sir.
None of that Microsoft 365 Email rubbish/Zoho
On another note, best of luck with your new(ish) venture!
They have full control of changing emails, while usernames are more permanent. I will have a look over this again before changing anything. Thanks for the feedback
Yes sir, GSuite is prem sir. Everything else sucks.
Thank you
Gsuite legacy is better.
Looks awesome @Jord :-)
Thank you
I'll post more screenshots soon.
Can't wait to try that baby out
Thank you sir, it can't wait to try you out too
Looks good! I am looking forward to the beta testing.
One concern, voiced by others as well, but I missed the reply (if any) ... our client data is private - between us and them. I think some would have an issue with a third party being able to access the data. What is in place to prevent you from accessing our clients data?
On to lighter subjects ...
I'd like to echo the self-hosted option, but understand your view. Self-hosted though would take the concern above off the table.
I am sure that you'll get lots of requests for this or that ... mine include:
NameSilo - for domain registration.
Transferwise - an integration to check TW account for incoming payment(s).
And potentially quite useful for many -- integration with popular accounting services such as Quickbooks Online, Xero, and Wave.
And lastly, for now,
what about the ability to track affiliate commissions?
Thank you, don't forget to signup on our Google Form link and we will get an email out to you when we go live for beta testing.
I've must have been in a bamboo food coma and missed it. But BillingServ is built on a multi-tenancy system. So every customer that signs up to BillingServ gets their own deployed DB. All the necessary details are encrypted. We are looking at extending this further also.
We currently hold our ICO (Information Commissioner's Office) Registration in the UK which makes sure we never share any client data and have policies in place to protect it, we also strictly adhere to GDPR.
None of our staff have access to our live systems. I am the only person with access to these systems. Our devs use test data to find and patch bugs on a completely different network. We are always making sure your data is safe. Our privacy and GDPR policies are in place to protect you. Plus our ISO 27001 procedures help with protecting customer data further.
Before going live we will be having a security audit on our system to make sure our codebase is safe.
Thank you, for the time being, we won't be going in this direction. We are focusing on our hosted platform.
Thank you I will get these added to our todo list.
We are going to be building our own accounting module so you can do everything under one roof. But we do have an export feature that will allow you to export a CSV for invoices/customers. We do have a Quickbooks integration.
This is also something we are looking at building in, it might not be in the first version, but it won't be long until it follows on
Any other questions please do let me know.
Personally, I wouldn't ever trust any third party company to host our billing system for us.
What do you plan to do when you need to run 24/7 operational on-call? Are you just never going to sleep? Or do you only provide emergency fixes when you're not asleep?
Or, worse, what if you get hit by a bus? Then what? All clients are left to rot?
What if your credentials are stolen? Do your operational controls use 2FA? What logs do you keep? What metrics you monitor for unusual activity to detect stolen credentials?
What is your deploy process? Who can deploy code? Is a code review required? What's the minimum number of people required to push new code? How do you ensure role separation? How do you detect and prevent collusion? What's stopping a dev who has their credentials stolen from trying to slip an innocent looking change that introduces a backdoor into production?
It would be much more interesting to hear you talk through your threat models, production operational controls (audit/authentication/authorisation etc), penetration test results, etc. The reality is, it's absolutely fine to have multiple people with production access - a bus factor of 1 is not a selling point.
None of my questions above are rhetorical - you'll find virtually any large software shop has controls to mitigate multiple threat factors.