Built for Rapid Innovation in the Cloud

We built Parlay the way we did so your team can innovate rapidly in the cloud. 

Before we started developing Parlay, we had to figure out what the underlying technology would be. There are a host of modern software tools that allow developers to create new products and services. The tricky part was deciding which technologies were best for what we wanted to create: a safe and reliable space in the cloud where innovation teams could collaborate in real-time to fuel rapid innovation. 

Group of female employees sit around a laptop at a desk to work on innovation efforts. 

The number of hours needed to create a basic web app is shockingly small – of course, a fully fleshed out product takes a lot of effort to design, build, test and iterate, etc. It only took us a couple months to get the first version of Parlay built and published for our initial set of pilot users. 

The biggest driver of ease-of-innovation for web apps is the rise of cloud services like Microsoft’s Azure platform and Amazon’s AWS platform. The existence of these services mean that small companies don’t have to purchase, assemble, maintain, and scale up their own servers. Not only does this save us a huge amount of time and expenses, but it also means that we weren't required to become experts in this technology, which means our efforts can be spent on higher-level activities like designing the product, developing core IP (intellectual property), and working with customers. However, these web platforms aren’t just for smaller companies; for example, Netflix lives in the Amazon cloud. 

While we considered using Amazon AWS, we eventually decided that our needs were a better fit with Microsoft Azure. We had used AWS on a previous project, and felt like Azure had a more refined user experience. Parlay's back-end API was likely to be written in C# (ASP.NET), which has a one-click publish-to-Azure feature. 

One thing the startup community has in common with the broader innovation community is the spirit of openness and sharing of knowledge. To that end, here are the technologies we use. To be clear, any experienced software engineer could easily figure this out by looking at HTML source code and network traffic. I’m just trying to save you the trouble and offer some editorial comments along the way. 

Public website and blog: Squarespace

  • A nice, clean, simple way to make websites. About a million times better than Wordpress. 

Web app front end: AngularJS

  • We had experience with the AngularJS framework, so that was an easy choice over the next logical alternative, React. React is gaining a lot of momentum, so we very well may consider using it in the future. 

API back end: ASP.NET

  • Again, we had experience with this toolset. Writing C# code is just delightful – it’s such a flexible and useful language. 

Database: Azure SQL

  • I know NoSQL databases (such as MongoDB) are all the rage in the startup world. This choice fits in the category of “stick with the thing you know and move on to other challenges.”   

Binary file storage: Azure Blob

  • Pictures and files get stored in Azure’s Blob storage. This is a super neat, fairly new product. We upload the file to the Azure Blob and get a unique identifier to retrieve it. Azure handles all the file management and backups.   

Email system: Sendgrid  

  • We use this for sending welcome emails, daily digests, etc. Sendgrid, which promised an easy integration (and delivered) was recommended by a friend and other options were only briefly explored. 

Payments: Braintree  

  • Now a subsidiary of PayPal, Braintree’s here for the long haul and makes it easy for Parlay to securely accept credit card payments in the app. It has a mature, user friendly implementation for the ASP.NET back end. 

Start-up life is a prioritization game — if you get too bogged down in learning a new database system when the one you already know will do just fine, you're going to miss out on the other million things that need your attention. While we were considering all our options for building Parlay, we generally settled on using the stable, previously released versions we knew would perform well. We’ll certainly migrate to newer versions at some point, but these weren’t fully baked enough for us to start using them. After all, we’re not doing this work for the sake of academic technology exploration – we’re building stable, reliable, production software for our customers.  

Parlay’s software – like most other software – will be constantly upgraded and tested as new versions of our core product will be released. New features will allow us to make Parlay better-looking, faster, and have more features. Layers of innovation from many companies are combining here to provide Parlay customers with an innovative product, which in turn helps create more innovations. It’s an endless, intertwined cycle.