Digital Innovation Examples, Case Studies | Digital Natives


We share personal stories, talk about lessons we
learned and discuss topics that excites us about
digital products development.

How we’re improving our company culture

Want to boost morale and productivity in your team? Start with building an honest company culture. Here’s how we do it at Digital Natives.

How, our in-house holiday tracker became our next product

When it comes to complex problems, simple solutions are often the best. Read how our in-house holiday management app became our next product.

Should you go for cheap, fast or good when developing products?

Is it possible to develop a good product cheap and fast? In short: no. But some sacrifices are bigger than others.

How we prioritize features: Taming the feature creep

When building a product, it’s easy to get carried away adding feature upon feature. So how to tame the feature creep and prioritize functionalities?

Minimum viable product, maximum benefits: How we’re building LiveRobe’s sustainable fashion app

Style doesn’t have to cost the earth. Find out how we built LiveRobe’s minimum viable product to validate the sustainable startup idea and what should come next.

Going peer to peer: How we revamped our performance review system

Like it or not, performance reviews are here to stay. We’ve rolled out a new competency-based, P2P-evaluation system. Read the lessons we’ve learned.

Fair p(l)ay: Time and material pricing in software development

How and how much to charge when selling your expertise? At Digital Natives, we swear by time and material-based pricing. Here’s why.

The next big thing or the next big flop? How (not) to create products 

Developing a viable product is not an easy ride, and we learned that the hard way in the past. See our blog post on the products we failed to bring to success and the lessons we learned from that.

A bugging question: who should pay for bug fixing?

In our last post we said that there is no such thing as “bugless” software. But in this case another question pops up: who to blame – and who to charge – when a software needs fixing?

This website uses cookies to ensure you get the best experience on our website.