Employee Platform Development Case: Adding Features to a Growing Product (Ziik)

This employee platform development case covers the features I built for Ziik, a growing social intranet and employee app for frontline teams. The short version: [PLACEHOLDER: one sentence on what you built and what it meant for Ziik and its customers]. If you run a SaaS or platform in Europe and need extra development capacity without making a new hire, this is what that kind of engagement looks like from the inside.

[PLACEHOLDER: confirm that Ziik has approved the company name, scope, numbers and quote in writing before publishing.]

The short answer

This is written from my side of the table. It covers working in an existing product, for its customers and in a codebase that was there before me.

The starting point: a live product used across many locations

Ziik's website lists retail, hospitality, food and beverage, transportation and franchise operations among the sectors it serves. That is a very different world from a desk-based intranet. Users are on a shop floor, in a kitchen or at a depot, phone in hand, with a few minutes between tasks. Customers are often chains with many locations, so head office, the local manager and the employee each need to see different things.

For a developer, that has three consequences:

• Roles and permissions are part of almost every feature.
• The phone is the main screen, and it has to work on a small display with a patchy connection.
• A bug can reach every customer's staff at the same time.

Then there's the GDPR. An employee platform stores names, roles and messages about real people, and under EU law that is personal data: any information relating to an identified or identifiable living person. Every new feature has to answer who can see what, and for how long it's kept. If your platform is based outside Europe but has EU users, the same rules generally apply to their data.

[PLACEHOLDER: Ziik's situation when you joined: why they needed extra development capacity, what was on the roadmap and how big the team was.]

What I built

[PLACEHOLDER: 2-4 features. For each: what it does for the user, who it's for (head office, manager or employee) and what made it hard to build or roll out.]

Before I write code for a new feature on a platform like this, I want answers to four questions:

1. Who should see and use it, and who must not?
2. What happens to existing data and customers when it's switched on?
3. How does it behave on a small phone screen with a weak signal?
4. After release, how will we know whether people use it?

They sound obvious. They're also the first things to slip when the roadmap is long and the deadline is close. A fuzzy answer to the first one tends to turn into a bug where an employee can see something only their manager should.

[PLACEHOLDER: a concrete example where one of these questions changed a feature during the work at Ziik.]

How I work inside someone else's product

When I join an existing platform, I spend the first days reading code, running the system locally and learning the domain before I change anything. On Laravel projects, Tinkerwell and Ray are my go-to tools for poking at data and code. The rest of my setup is in the tools I use as a freelance developer.

From there, I usually work in this order:

1. Define done. I agree with the product owner what "finished" means before the first line of code.
2. Ship small. Each feature is split so every part can go live on its own, ideally behind a feature flag (a switch that turns it on for selected customers first).
3. Test the expensive parts. Automated tests cover what costs most if it breaks: permissions, notifications and data separation between customers.
4. Follow the team's process. Code review, releases and documentation happen the way the team already works, not the way I'd prefer.
5. Check after release. I watch error logs and usage so we know the feature works in practice.

[PLACEHOLDER: how it actually worked at Ziik: meeting rhythm, tools (e.g. GitHub, Jira, Slack), code review, who you reported to, and what worked or didn't.]

I'm based in Denmark and work on Central European Time, which gives full overlap with UK and EU office hours and a few morning hours with the US East Coast. For a team spread across Europe, that matters more than most people expect.

When I own a project end to end, it runs differently, and I've described that in how a freelance development project works with me. [PLACEHOLDER: one sentence on how your role at Ziik differed from that, e.g. the team owned prioritization and you delivered into it.]

The outcome

[PLACEHOLDER: what the features achieved, with numbers Ziik has approved. For example how many customers got the feature, how much it's used, fewer support tickets or time saved for customers. No numbers without approval.]

[PLACEHOLDER: quote from a named person at Ziik, approved word for word, with name and job title.]

[PLACEHOLDER: what went less well or took longer than expected, and what you'd do differently today.]

What to take from this if your platform is growing

A growing platform almost always has more ideas than developers. The tempting fix is to bring in more people, but extra hands only help when the groundwork is in place. If a new developer is slow to get going, look at the setup before you look at the person.

Three things matter most. One person has to own prioritization, or the outside developer ends up guessing. Every feature you add also has to be tested, supported and updated for years, and forgetting that bill is one of 10 pitfalls in SaaS development. And a new developer needs access, a staging environment and documentation ready on day one. I've put that part in an onboarding checklist for freelance developers.

When a contractor is the wrong call

Outside development capacity works well when there's a clear task and a team that can take it in. It works badly in these situations:

• You need a full-time developer for years. An employee is usually cheaper over that horizon and becomes part of the company.
• Nobody owns the product internally. A contractor can suggest priorities but can't replace a product owner.
• You need 24/7 on-call cover. One person can't provide it, and a serious freelancer won't promise it.
• The lowest hourly rate is the main criterion. Danish rates are generally at the higher end in Europe. If price per hour decides it, a larger offshore team will win on paper.
• Your platform runs on a stack I don't use. I work in Laravel, PHP and modern JavaScript such as React and Next.js. If you're on .NET or Ruby on Rails, a specialist in that stack is the better choice.

Next steps

If your employee app or SaaS has customers asking for more than your team can build, write down the next two or three features. Note who they're for and what happens if they don't arrive. That's enough for a first conversation.

You can see how I help teams extend existing products on my page about custom web app and platform development. For larger engagements I start with a paid, fixed-price discovery phase, so we both know what's being built before the main work begins. The code is yours from day one.

Frequently asked questions

Can a freelance developer in Denmark work with an in-house team elsewhere in Europe?+

Yes, and for a growing platform it's often the most practical setup. The developer works in your repository, follows your code review and uses your tools for tasks and chat. It works best when the contractor joins your planning sessions instead of receiving tickets over the fence, so they understand why a feature matters and not only what to build.

How quickly can a new developer contribute to an existing codebase?+

It depends mostly on the codebase and its documentation. My rule of thumb is that an experienced developer should get a small change live within the first couple of weeks, as long as access and a staging environment are ready. If the code has no tests or documentation, expect longer, and consider starting with a short code review.

Do we need a data processing agreement with a contractor working on our platform?+

Often, yes. If the contractor can access production data containing personal data about your users, they are usually processing it on your behalf, and Article 28 of the GDPR then requires a written contract with specific terms. If they only work with anonymized test data, the need is smaller. This isn't legal advice, so check your own situation with an adviser.

Who owns the code a contractor writes for our product?+

You should, and the contract should say so explicitly. With me, the client owns the code from day one, and the work happens in the client's own repository. Also make sure hosting, databases and third-party services sit on your accounts, so you're never dependent on one particular developer to access your own product.