Small team. Deep experience. Useful software.
We've been quietly building as 2050 for six years. This is the part where we start being more public about it.
2050 has existed longer than this website.
We've been working as a small software consultancy since 2019 - mostly quiet, mostly client-facing, building useful things for businesses that needed them. The kind of work that doesn't show up on case study pages because the clients just got on with it.
We're making the practice more public now. Not because we've reinvented ourselves, but because the work has reached a point where it's worth writing some of it down.
The name is a number. It was always a number. It's not a claim about the future - it's a frame for thinking about work that should still be useful in ten years.
Mark Collister
Technical Person
Mark has been in software since 1996 - almost 30 years of working at the intersection of technical delivery and business problems. He started as a developer, moved into technical leadership, and has spent most of that time building the kind of software that businesses actually rely on day to day.
His stack is primarily open source, databases and infrastructure - with a long history of integrations, data work, Linux systems and legacy system rescue. He's been using AI-assisted development tools since they became useful, and is opinionated about where they help and where they don't.
"Building elegant solutions to complex problems."
Nicole Collister
Business Person
Nicole has 15+ years of experience in brand strategy, marketing, client service and business operations. She's worked across agencies and client-side, with experience in New Zealand and internationally.
At 2050, Nicole connects the business and client side of engagements - making sure what gets built is what the client actually needs, that communication is clear, and that projects stay on track. She's the person who asks the right questions before anyone writes a line of code.
Useful beats flashy. Production beats demos.
Build what the business actually needs
The most impressive demo is often not the most useful product. We resist the pull towards complexity for its own sake.
Fewer moving parts where possible
Every layer of abstraction is a future maintenance burden. We add complexity when it earns its keep, and leave it out when it doesn't.
Use AI carefully, not theatrically
AI tools are genuinely useful for parts of software development. We use them there. We don't use them as a marketing claim or a replacement for senior judgement.
Plain English, always
If we can't explain what we're building and why in plain English, something is probably wrong with the plan — not with your ability to understand it.