Two great opportunities have opened up to join the Seedcamp team! We’re a fun and friendly team that works super hard for our startups and we’re looking for two passionate and pro-active individuals to join us. If that sounds like you, read on!

Seedcamp Team

Office and Events Manager

Are you passionate about entrepreneurship and startups? Do you enjoy organising events? Are you someone who has faultless attention to detail? If so, read on!

Seedcamp has grown rapidly since 2007 and we’re in need of someone who can keep the wheels turning and ensure smooth execution of our office and operations. We’re a small team with a huge outreach and this is a unique opportunity for someone wanting to immerse themselves in the European startup scene. You’ll be at the heart of the London startup ecosystem based at Google Campus in Shoreditch working alongside various members of the Seedcamp Family. You’ll be in charge of making sure the office and team runs smoothly by working closely with the other team members. Plus, you’ll get to manage independant projects, administration, events and travel.

Excellent communications and interpersonal skills are essential, along with outstanding planning, time management and organisational skills. You should have a can-do attitude, bucket-loads of initiative, attention to detail and be able to work independently towards team goals.

The Job

About You

Bonus Points

To apply for the role please send an up-to-date copy of your CV with a short covering note to careers@seedcamp.com. Be sure to include examples why you’re the best person for this role.

Deadline: 11.59pm Sunday 26th October.

 

Technology Lead

Seedcamp is looking for an ambitious and talented full-stack engineer who is passionate about startups.

You’ll play an integral role within the Seedcamp team, helping plan and implement our tech strategy and manage the internal database. You’ll be willing to give guidance to our startups if they need advice in your area of expertise. Yes, it’s a lot of moving parts, but we are looking for a rockstar who loves tech and wants to make a difference within the startup ecosystem.

We look forward to hearing from you!

The Job

About You

To apply for the role please send your CV with a short covering note to careers@seedcamp.com. Be sure to include links to your work to show us how awesome a coder and hacker you are.

Deadline: 11.59pm Sunday 26th October.

Each year we visit over a dozen cities around Europe to meet highly ambitious startups looking to build global billion-dollar businesses. We’re always impressed by the high quality of startups on the continent, but we know that sometimes we miss those who are unable to make it to one of our events; whether they are based outside the city or have conflicting schedules.

So we’re launching Online Office Hours – a great opportunity to get early feedback on your startup, ask any questions you may have, and receive 1:1 advice directly from the Seedcamp Partners, Reshma Sohoni and Carlos Espinal. To make it super easy, we’ll be using Skype and Google Hangouts to host the calls.

We’d love to speak to everyone who’s interested, but spaces are limited. So you will need to apply using the country application links below. The deadline for applications is midnight Sunday 12th October.

Online Office Hours

What can I expect from Seedcamp Online Office Hours?

We’ll carefully select 5 startups from each country and teams will be allocated a 10-15 minute slot for a video call with one of the Seedcamp Partners.

It’s a unique opportunity to discuss your startup directly with our Partners, Reshma and Carlos; two people who have impacted hundreds of startups journeys. Additionally you will:

The Online Office Hours will be scheduled between Thursday 16th October and Friday 17th October. We’ll announce the exact time-slot for each of the 5 selected startups by the end of Monday 13th October.

Who should apply?

We’re looking for ambitious founders who want to build global billion-dollar startups. Our focus is on mobile and web, and we look for founders who use technology to disrupt large industries. You are at the right stage when you are anywhere between a rough prototype and a live product (some startups even have some revenue when they join Seedcamp!) If you don’t know if you are ready for Seedcamp or if we are a fit for you – or maybe you just want to get to know us better – we encourage you to apply.

What happens next?

Besides early feedback and top advice, meeting Carlos and Reshma might get you an invitation to participate in one of the upcoming Seedcamp Weeks; where you will spend 3 days meeting over 200 of our mentors and investors and see if you are one of the next members to join the Seedcamp Family.

How to apply?

SPAIN We’re proud to have already invested in Spanish companies such as Socialbro, Traity, 24symbols & Lodgify and would love to have more Spanish teams join our family.

Apply via AngelList or f6s before Sunday 12th October.

AUSTRIA We’re proud to have already invested in Austrian companies such as Codeship, Blossom & Platago and would love to have more Austrian teams join our family.

Apply via AngelList or f6s before Sunday 12th October.

POLAND We’re proud to have already invested in Polish companies such as GamingLive & Codility and would love to have more Polish teams join our family.

Apply via AngelList or f6s before Sunday 12th October.

About Seedcamp

Seedcamp is a new kind of fund supporting startups from the pre-seed and seed stage. We back ambitious founders from around the world and help them build billion-dollar global companies by providing them the right access at the right time to learning, network, and capital. We invest initially up to $250k and accelerate them across the product/market fit, traction, growth, and scale stages from seed funding to IPO.

If you’re not familiar with the Seedcamp events or would like to know more about the process, please read these reports from previous events, about investment terms, and our 6 most commonly asked questions.

Tweet us if you have any questions. We look forward to receiving your application!

Infrastructure development of a product often goes undiscussed – the thing just works, or sometimes it just works faster. But there’s plenty of important work going on behind closed doors. It’s not sexy but it is important; the long-term stability of a company’s product will depend on it.

Formisimo Senior PHP engineer Doug Read and his team have done an outstanding job of turning their Minimal Viable Infrastructure in to something faster and stronger (back in early 2013 Formisimo was running just one web server – a year later this had risen to over a hundred servers!) As the business grew it was important to grow its infrastructure too; it needed to be both robust and infinitely scalable. In this article Doug shares the method of how he ensured Formisimo’s infrastructure was best-placed for long-term growth.

Formisimo is a powerful online-form analytics tool, providing advanced data and insight to help increase your bottom line. This article was first published on Formisimo’s blog.

monolith

In its minimum-viable-product phase Formisimo was one web-server. This web server handled everything except the database – it was the don. It was a monolith.

There is nothing wrong with a monolith. It’s a great way to get stuff done quickly and in one place; however, for many reasons it’s not suited to applications that grow above a certain size (size of features and/or size of load). So as Formisimo approached leaving the MVP stage I thought about the architecture of the application and what shape it needed to be to allow Formisimo to be robust and infinitely scalable. The architecture I planned was the complete opposite of a monolith – a service orientated architecture. There are many branches to this planned architecture but it wasn’t long before a strain beared down upon the monolith helping us decide which bit to do first.

This project ended up being called Project XFactor – I think it was because we used the word refactor a lot. It focussed on the tracking side of Formisimo; receiving and storing all the tracking data we record on behalf of our clients.

XFactor’s goal was not only to improve the architecture and future scalability but to also bring immediate performance improvements. Clients had expressed concerns that the response times in their customer’s browsers was on the slow side, and we were aware of some short outages – we needed it faster and sturdier!

XFactor had 3 main tactics

  1. Decouple the need to write to the database before we respond 200 OK to tracking HTTP requests. Accessing the busy database added too many milliseconds to the response
  2. Extract the tracking elements of the monolith into a separate web service. Code this web service so that it can be load balanced and scaled out horizontally – this allows scaling specifically to the needs of the tracking load and also gives separation from the errors that may occur in the rest of the monolith (separation of concerns).
  3. Use a third party global CDN to distribute the static JavaScript files

None of these ideas are crazy or weird – plenty of people gone before us have done just this – they are proven strategies – and they’ve proved to work for us.

Decoupling the database

For the database decoupling I wanted to use a message or job queue. I have used these before and know them to be a great way of achieving this decoupling. As we’re currently hosted on AWS, SQS was a very quick and easy option and we went for this. We’re not staying on SQS long however – update on this coming soon!

Refactoring the tracking code

The tracking service was coded to be as dumb as possible – it does very little thinking as it has one job it does as quickly as it can. It accepts whatever gets thrown at it, puts it in the queue and says thank you very much. I like to picture it as someone saying “thank you” a millisecond before you finish your sentence. This led to amazing speed increases in our client’s customer’s browsers.

We coded the tracking service to work in any number of parallel running servers to allow us to scale outwards. With this in place we had the opportunity to determine an optimum balance between the number of servers and the power of those servers. At the time of writing there are between three and seven medium EC2 instances behind an AWS load balancer.

Service Orientated Architecture

SOA1

Traffic from the cloud hits a load balancer, then a Tracking server, then a Queue, then finally a Queue-Consumer which crunches the data. You may be able to guess that this is a diagram I drew by hand; ooohhhhhhh!

Of course if we have a service populating a queue we need a service consuming the other side of it – our Qconsumers. The tracking servers have the tiniest workload per request; in comparison the qconsumers have at least ten times more work to do per request. They have to parse and understand every bit of the tracking data to write it to the database ready for data crunching. We have between 50 and 100 servers each running 3 parallel processes which poll the queue.

The queue-decoupling gives a buffer between the realtime demand on incoming tracking data and the processing and insertion into the database – like suspension in a car. But we try to achieve what I call (does anyone else?) “almost realtime” data insertion. This essentially means that although we have the buffer in place, which allows the queue to grow to any size as tracking data spikes, our aim is that a request gets processed as soon as it lands in the queue.

Unfortunately this doesn’t directly benefit our clients yet as there is still some data crunching that has to happen before the data is readily available — this can take up to 24 hours. In the future we intend to pass the almost realtime benefits through to the reports the clients see.

Choosing a CDN

The CDN was another easy option as AWS CloudFront was right there. We created a new web service just for static content and have placed CloudFront in front of this and as you’d expect achieved even more speed into our client’s customer’s browsers.

 

That sums up XFactor but for a couple of technology changes; moving from PHP to Ruby. PHP is a fine language for a web service, but when your code isn’t 100% sat behind a web server you’re much better off picking a more general purpose language…. and no, I don’t mean Rails. And also moving from Apache to Nginx – simply as Nginx has better performance.

With this article I’ve aimed for brevity, but if you have any questions or want more details on our technical implementations then please feel free to email me or leave a comment; I love talking about this stuff!