About Red Ant

We’re a cross functional tech agency of Developers and Designers in Sydney, Australia. Hopefully this page tells you all you need to know about us and more.

To start with, we have a core team of 30 – a mix of developers, UX, design and project managers. We use Open Source software - our speciality is Ruby on Rails, Angular and React. We use an Agile project delivery methodology.

We’ve been around for a while (+22y) and in that time have worked on a wide variety of projects. Picking up quite a bit of know how and experience along the way. We specialise in creating and building Digital Products.

This page goes on for ever. No seriously, it really does. You need to be a real fan to read it all. Or maybe you’ve self medicated to get over a slight flu, and you don’t realise you’ve been staring at this screen for the last hour. Yep, those are actual real flying toasters. For real. You probably shouldn’t have more than two of those tablets.

So you might be asking yourself “how are these guys different to X?”. Well, it depends on exactly who or what X is, but here are some “X”s that we run into:

We’re different from that Digital Agency

Because we’re very strong technically. We have a culture of making great code, with systems and tools to back this up. We won’t get some freelance kid in to build your project. Because we do know the difference between java and javascript.

We’ll provide you advice and strategy based on knowledge and experience, rather than some blog we just read. And if we’re not sure we take some time to actually look into how it works. Rather than just trusting vendors.

We’re different from that offshore team

Because we can communicate clearly. We get it. We aim to learn very quickly more about your business or idea than you do. And we can conceptualise and build it.

Especially for complex projects, we know how critical it is that everyone has the same understanding of a project. Agile relies on having meaningful conversations rather than endless documentation, circular conversations and change requests.

We’re different from that smaller dev team

Because we can scale. We’re not a few guys in a coworking space. And we know how to build things that do scale. Scale might mean more traffic or higher transactions. Or it might mean more features. Or it could mean different types of team resources - like more developers, more design, or more project management.

We’re reliable and have super tight processes. So you don’t need to worry about a change here breaking something there. Again. Or whether the next deploy is going to bring down your entire site. Again. Or that we’ll just disappear.

We like to form close relationships with our Clients. We’d like to know as much or more about the digital side of your business than you do.

To explain: we spend a lot of time understanding how your business and software works. If we can learn as much as we can about your business, we’re probably going to be able to communicate pretty well. And from that we’ll hopefully get some fantastic results.

To do this we set up a dedicated team. Continually changing people sucks for all concerned - it is incredibly inefficient, and if a developer needs to continually context switch, they aren’t going to be particularly productive. For some projects dedicated means 5d a week, while for others it might be every Monday and Tuesday. Regardless, we try to keep the same people on a project, as experience has shown that this gives the best results.

Everyone on the team is an expert in their respective area. No passengers. The team uses the Agile methodology to deliver ideas, strategy, design and code. Let’s be as efficient as we can and not waste each other’s time or money.

Each of the teams focus on delivering projects quickly, that we can then iterate and improve upon.

Often we see ideas and executions from one team being applied on other projects. So that new way of running ideation sessions, that great mobile strategy, or the idea that halved page load time gets re-used once it’s been proven. Team members develop specific expertise, and they get shifted from team to team as those skills are required.

We share ideas and improvements via Standup sessions and Agile retrospectives. Transparency is key. Humans are particularly good at communicating complex issues quickly, rather than writing out lengthy specification docs.

This all might seem a bit strange if you’re used to dealing with traditional Ad Agencies or Management Consultancies. We don’t have junior account people. We don’t use Powerpoint. There isn’t some offshore team you’ll never meet that does the actual work. And we most definitely don’t have people who cause you to wonder what exactly they do again and why are they on your project.

Meet the Team

Travis CI

Continuous integration server
Each time a developer adds some code to a project, Travis grabs it, builds a virtual version, and then runs some automated tests to check if everything is working correctly. Continuous Integration has meant we have much higher reliability, and know as soon as a mistake creeps in to code.


Agile team leader
The most chilled out Chihuahua you’ll ever meet. Typically found sun baking in one of the meeting rooms until about 11, then it’s time for a nap. He was a rescue dog, so his past is a bit unknown – our little man of mystery.

Project Summary Tool

Issue tracking platform
Keeps track of everything. And I do mean everything. Visualises progress of each sprint, deliverables, and forecasts where we think we’ll end up.


Code repository
Each time a developer saves their work, it goes here. We can see exactly who changed what when. Developers can work in parallel streams and merge their work as required.


Deployment & Server Orchestration
One of the challenges with modern sites is deploying them to servers. There are lots of moving parts. We automate this so it can be repeated flawlessly.


Timesheets and transparency
Sure, everyone keeps time sheets. Well most people do. But ours are special- our Timesheet Bot connects work done with tasks in Jira and Git commits. So our clients and PMs can see exactly how much time got spent when to do what.

Code Climate

Code stink detection
We continually monitor our code, automatically picking for quality problems like unnecessary complexity, repetition, or test coverage. It identifies “stinky code” with an A through F ranking.

Ruby on Rails

We’ve got some relatively large clients & sites that we’ve been working with for a while. We specialise in a way of building these sites called Ruby on Rails. It helps us make things more efficiently and with greater reliability.

We use it to build

  • Membership sites
  • Reward point systems
  • Content management
  • Mobile sites and mobile applications

Why should it matter to you how we build a site? Well, there are a gazillion “ways” you could make a web project- WordPress, dotNet, Joomla, etc. Rails is just one. It just happens to be a very good way to build complex projects. Rather than being just OK in a variety of “ways”, we’ve chosen to focus on being experts in one – Ruby on Rails. It turns out that not only is it a great programming language for making web sites, it helps us work in a very Agile way, radically improve reliability and have a fully automated testing process.

Go back 10 years, Red Ant used to dabble in a bit of everything from ASP to dotNet to PHP. We paid many thousands of dollars to be fully certified Microsoft blah blah consultants of this and that. A few of our sites became quite popular, and we realised the tools we were using and our approach really wasn’t cutting it. These sites were failing under load, becoming more expensive to run and more complex to maintain.

We weren’t using these tools out of a conscious choice. Somehow it had just become that way depending on what our clients were already using.

So we stopped, thought about what we wanted, and changed tack. We had a careful look around at how other people were designing and building sites, and what kind of technologies were being used to make really big, really interesting and engaging sites. Spoiler alert: it wasn’t dotNet.

We ended up choosing Ruby on Rails, as it suits the kind of stuff we like to do. Not only does it help us make highly interactive and dynamic sites, it also has a lot of really well thought out processes baked in. These lower our project risk – because no matter how awesome your rockstar developers are, they will make mistakes. Having processes, like automated tests and deployment processes, mitigates this by giving us a way of doing something right, and then repeating it flawlessly again and again.

Read more about why we use Rails here

Ideas & Strategy

Ask pretty much any agency if they can help you with digital strategy and ideas, and the answer will probably be yes. Come to think of it, these days you could probably ask anyone you meet and they’re likely to have an opinion about your site and what you should be doing.

But there is a big gap between the talking and the doing. Especially in digital, so much rides on experience and a deep understanding of technology. Good luck to you if the agency advising you has little direct experience in the “doing” and subcontracts the actual work to someone else- I’m sure you’ll get a fantastic looking something.

You might have heard of the story of the Fat Smoker. He is really fat, and he smokes. He’d like to live a long and happy life, so he asks various people which strategy he should follow. Everyone advises slightly differently, but they are essentially variations of the same thing: he should lose weight and stop smoking.

Unfortunately that is the obvious bit. The easy part. Being able to talk about simple strategy ideas is very different from actually having something in place that works.

To achieve weight loss and giving up smoking, he’ll need some specific plans and tools. This might need to be adjusted along the way. Maybe what worked for the first month will be very different to what is needed to lose that last 5 kg.

So really doing it – losing the weight, keeping it off, and giving up smoking – is the hard bit.

We can help you with that hard bit.


You might have heard about Agile and wondered what it is all about.

Agile is a way of defining a project with the end user in mind. Say we were designing an aeroplane, the definition wouldn’t be about making an aluminium tube with flat things sticking out. Rather, it would focus on user requirement- eg something which can get 300 people from Sydney to Tokyo within a day.

It also involves breaking work up into a series of “sprints” – at the end of each sprint we’re aiming to achieve certain goals.

Agile also involves the client, via a technique called “showcasing”. This is where we regularly meet to review the site as it takes shape, rather than having a big “tadaaa” moment at the end. Instead of putting effort into making a big specification document at the start, we focus on having meaningful ongoing conversations about how things should work. Along with overall strategy, we know the project may change as things develop- something that seemed sensible at the start might be done better another way.

One of the best analogies I’ve heard about Agile is a military one.

Non-Agile: think WWI – the Generals would plan out their campaign months in advance. Orders were written out in great detail along with intricate maps, and sent to the troops. At the designated time, thousands of troops would rally and carry out these orders. Disobeying an order will get you shot. The Generals might not hear about progress and result for hours- sometimes days later.

Agile: think modern warfare, with much smaller, highly trained teams that move quickly. The overall objective is defined as getting to that hill, and this is simply and clearly defined and then discussed. Everyone in the team understands the critical bits, the “nice to haves” and the overall objective. But how the team actually gets to the hill is driven by the guys on the ground. New information might come to light during the day and the situation will change. They communicate regularly between each other, and back to command- all in real time.

Automated Tests

Automated Tests are an integral part of the way we work. When I say “test”, you might think that means we check work once it is finished. We do, but these are different. The easiest way to think of a “test” is as a way of describing how something should be. These get made into automated scripts, and in the course of a project we’ll make thousands of these and we can then check them continuously.

We follow a process called “test driven development”. What that means is rather than starting a project with a set of photoshop images, we try to describe what your site should be as a set of features. These core ideas then get fleshed out into more detailed features and wireframes, which become the start of our test code.

These tests check how something should be: what should happen when I visit that page or press that button? These tests gradually get added to and refined, until we are confident that if the tests are passing, the site works OK.

Think of these tests as kind of like those spikes that rock climbers tie their rope to. You might slip during the climb (the slip being some code change which inadvertently breaks a feature) but you won’t fall all the way back down.

To give an example of a test: your site might have members, and you want them to be able to log in and update their profile image and username.

Off the back of this, we could create a simple test, which checks that a user can indeed update their profile image and username. At the start this test will fail. But then a developer designs and builds a form so that a user can indeed log in and update this information. The test starts to pass.

The actual “tests” are scripts which mimic user behaviour to see if something is working. So one test might check the actual code to see if the form logic means it is editable. And another would fire up a virtual browser and pretend to be a real user- filling out their profile and saving an image.

Several months later, a developer makes a change which inadvertently hides the profile image- so users can no longer update their profiles. Which would really irritate some users. Which would be Bad.

But that simple test we had in place right from the start checks this. That test will fail even before the code is committed- alerting the developer to fix it.

Someone set us up the Bomb

Oh wow. You’re still here.

If you’re down this far you’re either lost, or you’ve fallen asleep and just woken up. Or maybe you are interested in finding out more. You can see what we look like on our Flickr, you can stalk us on LinkedIn, Google+ or follow our Twitter. You can even walk around our office. Or you can simply pick up the phone and call us on (+61 2) 9267 8300.

Cancel Request a refund for time spent on this page

Let's build something awesome together

Hire us