Schoolyear is the leading company in fraud prevention for university exams in The Netherlands, with the ambition to expand worldwide. We are a young startup that has grown to a team of 12 people (7 engineers), 100+ institutions, and administers 150K+ exams per month over the last 4 years. Our focus is on building high-quality, stable software and providing a well-supported product to every institution globally. We are a bootstrapped company prioritizing product quality, team cohesion, and profitability over capital-funded growth. Our team works hybrid and/or fully remote from all over Europe (CEST±1h), with our HQ in The Netherlands (Den Bosch).
Schoolyear (Remote CEST±1) - we're a fast-growing start-up based in The Netherlands. Our aim is to simplify IT for educators, allowing them to focus on what truly matters: teaching.
We're looking for a backend engineer that loves to work in a small, fast-pace. We're looking for a new team mate that likes the challenge of building rock solid infrastructure, and also likes to build products that people like to use. At this role you can combine the two.
In our team we believe "boring" infrastructure is better infrastructure.
We're a tight team (11, 6 engineers) working from all over Europe, all with our own core skills. We work in 8 week development cycles (6 sprint, 2 cooldown) and we have strong technical leadership. We meet up 4 times a year in a team mate's city for an on-site week.
Schoolyear (Remote CEST±1) - we're a fast-growing start-up based in The Netherlands. Our aim is to simplify IT for educators, allowing them to focus on what truly matters: teaching.
We're looking for an engineer that loves to work in a small, fast-pace team to lead our development of a 10k+ node desktop streaming cluster. Tackling challenges like low latency video streaming, multi-vendor orchestration, aggressive auto-scaling and complex networking.
We're a tight team (11, 6 engineers) working from all over Europe, all with our own core skills. We work in 8 week development cycles (6 sprint, 2 cooldown) and we have strong technical leadership. We meet up 4 times a year in a team mate's city for an on-site week.
This is not your usual CRUD job. We're building the largest Remote Desktop cluster for examination in the world. We're looking for engineers interested in Desktop streaming, low latency networking and hardware resource management.
We're a remote, synchronous startup in The Netherlands with a team all through Europe.
Nope, we don't have write access to the config. It's manually configured by the universities through the admin console. We first through some admin deleted the config by mistake, but then it started happening for multiple universities.
We help universities simplify digital exams (on-site) by locking down devices and streaming desktop applications. Our job is done when any professor can organize an exam without the help of the IT department and the students don't really notice they're using our app.
We're a team of 9, mostly remote, all over Europe. We're a 3yo bootstrapped startup with 1M+ in ARR.
Challenges we work on:
- Peaky traffic. Some weeks we have 50k+ users, other weeks <200.
- Native software that has to run smoothly on many different devices ranging from potato laptops to chunky workstations. Up until now we ran on 6k+ different laptop models (300k+ devices in total).
- Large, multi-tenant VDI clusters scaling up and down rapidly.
- Our users are very non-techsavy while they the underlying infra they're managing is quite complex. Dummy-proof UX is fundamental to our mission.
We try to keep our stack simple: Go, Postgres, Vue, Electron, C++
I've been wanting to use render for a long time now at our startup, but last time I looked at your GDPR info it was lacking.
We sell to public education institutes in the EU, so it is a make or break for us.
We might not be your target customer in that case, but otherwise I would love to hear what is possible.
From what I can see, the research method is quite flawed.
What if drinking more coffee or tea makes you die younger? This would result in the same data they base their conclusions on.
E.g. dementia en strokes correlate with age. If you die young because of high coffee consumption you wouldn't show up in the "drank coffee and subsequently had a stroke" group.
Stateful, exaclty once, event processing without the operational capacity to run a proper Flink cluster. This thing needs to be dead simple, pragmatic and cheap/simple to operate and update. The only stateful part in our infra at the moment is a PG database.
We are going to start work on this in a weeks, so I'm looking for some insights/shortcuts/existing projects that will make our lives easier.
The goals is to process events from students during exams (max 2500studnets/exam = ~100k-150k events) and generate notifications for teachers. No fancy ML/AI, just logic. Latency of max 1 min.
Our current plan is to let a worker pool lock onto exams (PG lock) and pull new event every few seconds for those exams where (time > last pull & time < now - 10s). All the notifications that are generated are committed together with a serialized state of the statemachine and the ID of the last processed event. Events would just be stored in PG.
This solution is mean to be simple, be implemented in really short timeframe and be a case study for a more "proper & large scale" architecture later on.
Any tips, tricks or past experiences are much appreciated. Also, if you think our current plan sucks, please let me know.
Thanks, I had a lot of discussion with my founder about funding. Until now, I'm happy we did it bootstrap.
To answer your questions:
Model: B2B, mostly public educational institutes with 10k+ students.
ARPU: would be dumb to shared, but just under the EU tender limit, so sales cycles are reduced to minimum.
LTV: That's a hard one when you sell yearly contracts and less than 10months old. But from what we see, schools are very loyal customers.
Marketing: Lol, we have a website that we made with a 20$ template. It's all word of mouth and cold calling
Balancing study and work is REALLY hard (and source of struggle with my parents, which I totally understand :) . We managed to get an office on campus, so it's literally a 3min walk from the lecture hall to the office. Besides that, I was never big on "planning", but now I'm usually planning a month ahead on the uni assignments.
Mainly struggling with expanding the technical team. We have some freelancers, but developers in NL are harder to find than diamond.
How did we find the idea: actually came up with the idea during a meeting with teachers in high-school. They were complaining about the chaos the newly introduced laptops caused during classes. Then I learned the hard way that people that put money were their mouth is are your only real customers (yes, I got screwed over by my high school). Luckily, higher education is more willing to pay.