GDPR is a massive topic in the tech community with lots of work being required as well as limitations on what you can do to be compliant with it. We believe that it will have a massive effect on the tech landscape in the upcoming years as more and more court cases decide what is and what is not allowed.
First things first, what is GDPR actually? GDPR is an EU law that gives people more control over their data. Specifically how and who processes it.
The rights GDPR gives you:
The requirements GDPR puts on companies:
We predict that in the future companies will start moving away from managed SaaS applications for their generic needs and instead start using on-site applications instead. That is instead of using a third party A/B testing system they will use an on-site A/B Testing system like the one Parthenon provides.
One of the issues we foresee with the GDPR moving forward is the requirement to ensure that vendors are GDPR compliant. This could be from various levels such as in the case of using Mailchimp where a company in Germany was found to be in breach of GDPR because they failed to ensure that Mailchimp didn’t fall under the US Intelligence laws on communications. Luckily for the company involved the courts accepted it was a minor usage that had stopped and didn’t give them a fine them. However, in the future companies may not be so lucky.
Another reason we foresee a move to on-site application instead of managed SaaS applications is the requirement to report data breaches. Due to the requirement to report data breaches and inform users we think that companies will want to avoid the negative PR that a data breach of a vendor would imply for their company. Reporting a data breach is not fun, having to report a data breach can be an expensive process. We think having to do this work because of something outside of your control will make it even more unpleasant and make companies want to take back control of the data and process it themselves to avoid the negative PR.
We foresee that companies will have to start fetching data from all of their vendors whenever a user requires a data export. Having to fetch data for multiple sources before being able to provide the export may bring in personnel overheads as some companies may not provide an automated way of doing the export. However, when you have something on-site you’ll always have access to the database thus making it easier and faster to provide full data exports.
Parthenon helps by….
As a non-technical founder, you can be worried when you’re having a project built but do not know if it’s good or not. We want to help non-technical founders better understand what is happening so they can make informed decisions.
The code seems like it would be one of the hardest things to be able to correctly judge as a non-technical founder. However, due to the tooling created to help developers, this is one of the easier things to judge since you can use these tools to get a report about the quality of the code. These tools are called static code analysers, and you can find them running in the cloud, so you won’t even need to install anything technical on your computer to be able to use them.
For example, you can use SonarCloud to analyse your code, and it will give you back a detailed report of what it found, such as issues and its rating for the code. While this is not a hard and fast system, it will provide you with a good overview of the quality of the code.
It should be noted that for an MVP, you do not need really good code quality. You want the code to work and be of reasonable quality. You want to avoid major issues. Medium and minor issues can wait until you’ve passed the MVP stage.
For nearly every sort of application these days, you will need some sort of web infrastructure. While this can seem daunting for an MVP, this is reasonably easy to judge. There are three things you want to look at – the hosting provider, the server setup, and then you also want to check to see if it can handle the number of users you are expecting/hoping to attract.
To start off, it’s probably best to use a cloud provider like Digital Ocean. It’s very easy to use. Other cloud providers like AWS and Google Cloud Platform are geared more towards tech professionals using it. Digital Ocean has a very low barrier to entry and has a simple point and click. Once you gain some traction, it is reasonably easy to move off Digital Ocean whereas it’s harder to move off AWS and Google Cloud Platform.
With your MVP server setup, you want to be able to grow and scale. The easiest way to do this is to have a large database and then have multiple web servers talking to the database server. You will want to have your domain pointing towards a load balancer, a server that forwards requests to the web servers and makes sure each web server gets the correct share of the users. With this approach, when you get more users and need more web servers, you can just add a new web server to the load balancer and you’ll be able to handle more traffic.
One important thing you’ll want to get your tech professionals to do is to make it so that you can add new web servers very easily. To do this, you’ll want to have them create what is called an image of one of your web servers. An image is basically a backup that is easy to use to create new servers that are the same as the server that got backed up.
Load testing is when you use tools to pretend that there are lots of users using the application. This is good to know how many users your application can handle on the servers you have. It is also good so that you can see how fast it performs. If you have a slow website, your Google ranking wouldn’t be good, and users won’t have a good experience.
To do load testing, you can use cloud tools such as LoadForge. With this tool, you can record what you do in your browser and use that for load tests. Once you run them, you’ll be able to see how much traffic you can handle and if it meets your expectations.
Your database is one of the most important parts of your system. If you can scale your database, you can scale your application. The key to being able to scale is using the correct type of database for your data and the links they have.
A relational database is best for, well, relational data. This is data that is linked to multiple other bits of data, for example, if you have users that are linked to charging sessions that are linked to charging stations that are linked to companies. A company can have many charging stations, a charging station can have many charging sessions, and a user can have many charging sessions. Charging stations and charging sessions are linked to two different bits of data. Then you have relational data that would be best served by using a SQL database like MySQL.
A document-based database is good for data that is not linked to others, or data that is linked to it is only linked to it. For example, you have a blog that has posts, and the posts have comments. The comments are only connected to the posts and can’t be linked to anything else. With a document-based database, all of this data would be stored together in what is known as a document. In your application, when things are only related to one other item and can’t be linked to anything else, then you would be best served by using a database such as MongoDB.
Testing is an important part of the software creation process. No matter how well you do it, there will still be bugs, and people will ask why you didn’t test it. With an MVP, you’re looking for the showstopper bugs; when these happen, the application is completely unusable.
Testing can be a very boring process, and it’s quite common that when a developer changes one part of the application, it breaks another part of the application. This means you would have to test every part of the application every time there is a change. This isn’t feasible. This is why it is extremely common to write automated tests called unit tests that test the code in an automated way. This allows you to test everything constantly without having to spend countless hours clicking through the same area. If you have unit tests, you will want to run those tests every time you change something. To do this, you’ll want your tech professionals to use what is known as a continuous integration system.
Depending on how much you’re paying, you may or may not expect the developers to create automated tests. If they are not doing these and you’re doing the testing yourself, you will want to create your own automated tests using something like Ghost Inspector, which will allow you to create automated tests based on your browser. What you would want to test is your most critical paths, such as the user sign up path. These paths are the core things you want users to do on your application. If these paths don’t work, then your application will be useless.
Doing user testing seems very easy, but it is a skill in itself. This is why there are QA professionals. Most people, when they do user testing end, up just doing what is known as the happy path, which is testing if everything happens the way it’s supposed to work. The thing is, most of the bugs found are from users attempting things never meant to happen. One example is typing the word “ten” in a field that is expecting a number. When you’re doing user testing, you want to sit and think about what can possibly happen and then see how the application works if you try it. Here’s a good example of something that can realistically happen and realistically break. You have a user sign-up form and ask the users to enter their information into the fields, but they miss a field. It is a common occurrence where validation breaks but the user form can be submitted even when it shouldn’t be submittable.
In software development, free open-source software (FOSS) has always been important and without FOSS, IT would not be the same as it is today. It is hard to think of a company in this world today that isn’t relying on FOSS for part of its tech stack. For many developers, FOSS is a major part of being a developer and they feel like contributing to FOSS is something they, as a good developers, must do. Some loath the idea of commercial software. So it’s with this in mind, we feel like we should explain why we choose not to use the FOSS model. Instead, we have gone for commercial licensing. ANd we
FOSS is great but it is commonly worked on by volunteers who have day jobs working on other things, even those who are being sponsored by a company to work on the project are so overwhelmed with the amount of work they are unable to provide the same level of support you can get from a company selling software. Support is a hard job, support is also a job that requires skills that many people do not have. So even though the volunteers who work hard on FOSS want to provide the best support possible, they are limited by time, resources, and sometimes skillset. With the money, we make from selling Parthenon we can invest in ensuring that users get a good level of support. We can invest in ensuring that critical bugs are fixed in a timely manner. There are many FOSS projects that are amazing but they have small bugs in them with remaining unfixed for a large amount of time because the sole maintainer of the project is busy with the important things such as spending time with their loved ones and the FOSS project is a side project that they may only invest a few hours of time in per month. With commercial software, we can ensure developers have time to fix issues and still have free time to enjoy their lives.
The importance of documentation for a software library can not be overstated. If you ask any FOSS project what they would like help with the most, we believe that the majority of them would say with their documentation. The thing with documentation is, it’s not sexy, it’s not the most enjoyable task, etc. However, it is probably the most important task. When you see a problem with the documentation with a FOSS project, normally the only real answer you have is to fix the problem yourself, if you’re able to. You may not have the technical expertise or time to figure out what the problem with the documentation is. There is the option of creating a bug report but there are no promises on if and when that can get fixed.
After over a decade in IT building things on top of FOSS, I’ve experienced one thing quite a few times that you can never expect from FOSS and that is to be designed for change. Athena was born out of the experience of working with Sonata Admin which is an extremely good admin framework. The company I was working for built their back-office system heavily on Sonata and we ran into several issues when it came to growing as a company and a tech department. One of the core issues as it is only designed to support SQL databases and Document databases using a specific set of libraries. We moved some data to a microservice that we only had access to via HTTP. We spent a week looking into modifying Sonata in a way that would allow us to continue to use it. We decided after a week, there was a way but it would take us less time to just build a separate admin system for this data. This is in no way a fault of Sonata. Our use case is not a supported use case.
Another issue we had was with scaling and having Sonata deal with large amounts of data. Again this is not something Sonata is designed to do and the libraries they use are also not designed to do what we were doing. Again, we ran into an issue that the FOSS we are using was not designed to do and was not part of their mission.
I wanted there to be an admin system that could do these things and I wanted it to be in the mission statement that is the purpose and provide guarantees. Commercial licensing allows this.
One of the core things with Parthenon that we wanted to provide was SLAs. We really want every company building software to have SLAs on the software. And we honestly think commercial licensing is the only way to achieve it.
The following guaranteed bug response times:
Check out the pre-order offer at https://humblyarrogant.gumroad.com/l/parthenon
Every company needs a way to manage its application and deal with issues such as customers locked out of their account or having problems using the application, and staff maintaining the data required for the application. All these things need to be done by the staff using software to run their business. This is why we built our Symfony Admin system, Athena, a place where you can control what is happening with your business.
Athena makes it extremely easy to add new sections. This allows your developers to work on crucial business logic to improve your product instead of being bogged down with the basics of building yet another Create, Read, Update, Delete (CRUD) system that has been built time and time again.
With the creation of a single PHP class file, you can add an entirely new section to your Athena. Each section will allow customisation of the functions for that section. Decide if something can be editable, for example, on a case-by-case basis.
Athena has been designed for you to use any database on a case-by-case basis. You can use one database for one purpose and another for a different part of your system; Athena can manage it. You can even use micro-services. The possibilities for fetching data are almost limitless. Unlike other Symfony Admin tools, Athena gives you the flexibility to grow without worrying about having to build a new back office to allow you to manage data in a new system.
Like all other Symfony Admin systems, Athena allows you to add entirely custom functionality beyond just the common CRUD functionality. If you need complex custom features unique to your business, you can add it to Athena with just a few lines of code and enjoy all the benefits of your new functionality. Athena ensures that your staff can manage your software in a single place and avoid administering your application in multiple locations.
You can see our Symfony Admin system, Athena in action at our demo http://agency.parthenon.site. Log in as the employee and then go to the back office. You’ll be able to try out Athena as it would exist for an influencer marketing agency.
Or if you’re more technical you can check out our documentation at https://docs.getparthenon.com/athena/
Parthenon is a Symfony bundle to allow companies to focus on their core business and have the generic business logic handled for them.
After over a decade of developing systems for a range of businesses, we’ve noticed that the majority of businesses have roughly the same requirements and needs. All that resulted in was teams of developers all building generic business requirements—and not focusing on their company’s core business logic. Parthenon is our attempt to provide a solution for this. Parthenon brings the generic business functionality allowing companies to build Symfony applications and focus on their core business logic instead of generic business use cases. While allowing systems to grow as the company grows.
Parthenon will allow you to start your business project with all the core functionality to get going quickly without writing generic functionality yourself.
Nevertheless, Parthenon is not just to start your business but to grow your business, with features such as A/B testing designed to help you grow. And our roadmap includes adding more features to help companies grow in the future. As part of our outlook of building for the future, we’ve designed Parthenon to be replaced, allowing you to grow to the point you outgrow Parthenon without having massive technical tasks to keep things still working after you replace parts as you grow. Parthenon is not coupled to any database system this allows you to start with one database and grow until you need to move to a different database system.
The reason we’ve chosen the licensing model we have is that we believe companies should be able to build their software using tools that have licenses and support guarantees.
We support many issues that are often not supported in open source projects due to them being out of scope. From general bugs to performance issues to feature requests. We believe that things such as scaling are an important aspect of our product and want to ensure that our customers can scale without our software being a hurdle to them. We understand that there are things that a company needs to operate that are outside of its core business and would be better suited to be outsourced. We want to be there to support our customers in the best way possible.
Here is a quick rundown of some of our features, we’ll provide a more in-depth breakdown for them in future blog posts.
Nearly every system needs a user system and what we bring to the table is a user system that allows for teams and inviting users.
Parthenon provides common functionality and wrappers. Such as queues publisher/consumers, PDF generation, monolog handlers, file uploading, ec.
Parthenon comes with its own Goddess of Wisdom, Athena. Athena is your go-to place to understand your application. Athena is an admin/back office system that is easily extendable to allow your employees to easily manage your application and action things for customers.
Parthenon allows you to easily test changes to your application and see the difference in conversions and actions taken by the user based on which variant of your application they see.
A system that allows for easy adding of actions based on data being saved. For example, no more having to have a developer spend a day writing code so that every time a company with more than 500 employees signs up, Sally from sales gets an email.
Parthenon allows you to create invoices quickly and easily. With multi-country VAT support being able to correctly identify which VAT to charge for SaaS clients will be easy as pie.
Parthenon will allow you to create multi-step forms with absolute ease. From custom complex onboarding forms to multi-step signup systems, you’ll be able to quickly build it and move on with more pressing matters.
All the things required to get your site up and running on servers. Such as ansible, ELK (elasticsearch/logstash/kibana) configurations, etc.
Parthenon will allow you to instantly accept payments via Stripe. Allowing you to generate revenue as quickly as possible.
To build a flexible foundation for companies to build upon, we built three applications using various technologies to power it.
We built Easio a sales pipeline tool that allows for the creation of custom Kanban boards with custom fields. This is built upon using MongoDB.
We built Ootliers an eCommerce sales monitoring platform that is built upon MySQL and TimescaleDB.
And finally, we built a demo application that uses the business model of an influencer marketing agency. It allows you to see Athena in action, see the extension of the CRUD system, the invoice system, and much more. You can check it out at http://agency.parthenon.site.