1. Top 1% Talent

Decades of research show the most important factor for software development success, dwarfing all others, is developer quality. Even more so than in other engineering disciplines, developer quality is the key factor for software project success.

Our chief software architect studied Computer Science at Caltech, one of the top science and engineering schools in the world, won first prize in a national software development contest sponsored by Apple Computer and the Smithsonian Air and Space Museum in Washington, D.C., after which his work appeared in the Smithsonian for 17 years. He has developed software systems in over a dozen computer languages. Systems he developed have been used in the US, Canada, Europe, and Japan.

Our development lead is a startup veteran who designed Walt Disney Feature Animation’s digital animation pipeline. Our design lead has nearly two decades of experience working in digital media with top consumer brands. And we’ve stayed small enough that these leaders are able to take an active role in most client projects.

We have been creating systems for over 25 years, from databases for space probes, to fund raising systems for non-profits, to an accounting and control system for DNA synthesis machines, to, most recently, a complete (and now mobile via the iPad) solution to manage low income housing development. Large, small, complex, simple, and in-between, we do all sorts of projects. Whether doing work for a small three person machine calibration company, or a major NASA research center, we love the variety of challenges our clients bring, and love seeing them succeed.

2. We Speak Your Language and Understand Your Business

Gary, a Caltech grad and friend of our founder, works at Google doing mathematical modeling for Google's AdWords marketing system. Gary is a staggeringly brilliant computer scientist, and, like many of his colleagues at Google, he loves solving incredibly complex puzzles, thinking deeply, and closing his door to work in silence while delving into computer science challenges. Gary is one of the smartest software engineers in the world, and at Google, as well as in his previous jobs doing original research in machine vision and image processing, he and many of his colleagues work in a world of data, algorithms, and the remarkably beautiful logical machines we call "software."

We get that love of software. We share it. But at Mighty Ant DataWorks, we don't work in that world. We work in daily and continuing contact with our customers. We talk to them on the phone, we learn about their businesses, we uncover underlying business goals, then provide software to get the same work done in a fraction of the time. But we aren’t computer scientists — we’re engineers. We don’t research new mathematical models, we apply the best techniques to solve problems, building the software equivalent of bridges and skyscrapers. And unlike Gary and most of his colleagues at Google, we talk with customers every day. While we love predicate calculus, neural networks, and the joys of recursion just as much as the next Googler, we also love talking to people. We partner with you to learn your business and then speak in your language. Solving problems for real people is why we come to work. We love to see a client's face light up when a report that used to take a week to manually prepare now appears automatically in seconds.

Our engineers answer their phones. We specifically chose work where we can interact with customers, among many other job options available, just so we would have the chance to talk to you. Want proof? Give us a ring. Our number is at the bottom of this page.

3. Top 1% Results

In 29 years Mighty Ant DataWorks has never failed to deliver on its technical promises. In an industry where complete failure happens almost half the time, that’s not typical. The quality and capabilities of the systems we create are also well outside the norm. We often create systems with a 10x schedule and cost advantage over our competition. We have done in months what others take years to achieve. We have done for 60k what others have spent half a million to do. We’ve written more about this striking finding here.

4. We Stick Around

We have worked with many of our clients for over 10 years, some for over 20. The longest we’ve supported a single client is 27 years (we’ve been in business for 28.) This makes sense. When you make great systems, and support them well, people keep calling. Great software has to be pried out of the dead hands of your employees to get them to stop using it (though, of course, we prefer the "give them something better" method of upgrade over the "death plus crowbar" software migration path.) Great software companies, and great software support, are hard to part with.

5. We Have A Flexible Development Methodology

Our development methods let us build to schedule, build to feature, or build to budget. We have large datasets of our own performance we use to estimate new projects, allowing us to tell you, once a project is defined, what a project will cost, and how long it will take. We can work on a weekly basis, or we can do major work for a guaranteed flat fee.

Many of our competitors advertise that they do Agile Development — a currently trendy lightweight development methodology using less up front planning, frequent, visible milestones, and which involves structured customer interaction in an environment of evolving project requirements. Agile methods are a great fit for some projects, and we often use them ourselves. But some Agile competitors do not do flat fee projects saying such projects are "impossible." Some of our competitors aren't set up to do robust requirements analysis, but for us, that's where a job starts. While we use agile where it’s a good business fit, we also match development methods and development lifecycle selection to each project’s needs. We have decades of experience in doing full requirements gathering, up front high level design, and construction of large systems on a guaranteed budget. Guaranteed functionality for a guaranteed price is the right choice for some projects. And while every project faces changes and refinements as it comes together, we adapt to changes in a carefully managed way to still meet budget and schedule.

6. We Don't Build From Scratch

Many engineers love to re-invent the wheel. We’re huge fans of beautiful pre-designed wheels if they get the job done. We take ample advantage of open source frameworks, projects, and other tools. And over the years, we've also developed software subsystems we can re-use, so when we build, we don't build systems with bricks, but with prefab walls.

We have proprietary intellectual property to help with reporting, graphical interfaces, data synchronization, document handling, email integration, navigation, web integration, and much more. If we do a modest project for you that takes us a few weeks to do, the actual system we deliver may have system features that took months to develop, and which have been tested, refined, and improved for years. The intellectual property we include in systems is one factor in creating our 10x cost and schedule advantage over many competitors.

Below are things we sometimes heard from people who call which suggest we aren’t a fit for them. We’ll leave out things like "I’m a well known internet fraudster who has been charged by the FCC several times for crimes but would like you to build a fancy new software system I’m unlikely to pay you for," as we’ve never had a client actually say that to us (we had to Google that prospect to find out!) But below are things we do hear from time to time on a first call.

“I already know exactly what I need. I just need someone to build it.”

Mighty Ant uncovers core business opportunities then creates high return on investment systems which exploit those opportunities. We’re some of the best in the world at doing this. If you already know exactly what you need, and perhaps also exactly how it should work, then you’ve already done the most important part of our job. If you’d like to design your custom software yourself and then just have someone else build it, there are plenty of firms who will be happy to take a stab at it, and we wish you, your project, and those other firms well!

We dramatically outperform firms that just try to build what they’re told — but to do it, we need to get to the underlying business reasons for building a system in the first place.

“Bottom line is I will only hire the cheapest heart surgeon.”

Well, good luck with that. When you have someone improving the heart of your business, we suggest you shop performance, not price. We create systems to maximize profitability, not to minimize cost. If you need to get to your job to make a living, the cheapest car to do that might be a 20 year old Chevrolet Cavalier for $250. The most expensive might be a 2016 Lamborghini Aventador for $449,950 (that’s the used price -- though it has pretty low miles.) Neither is your best bet. A 2 or 3 year old mid-range car in good condition with low mileage is a much better return on investment than either of these other two options. The 20 year old Chevy will leave you stranded by the side of the road not earning your living. The Lamborghini will strand you in bankrupcy court (although at 13 miles to the gallon, it gets better gas mileage than you might think.)

We suggest you shop not based on price but on performance, because "cheapest" isn’t cheap anymore when you’re stranded beside the road and can no longer do your work.

“We need someone to just finish up this IT project that’s almost done. Four other consultants have failed on the project, but if we could just find someone good to finish the work we can get it wrapped up. There’s just not much left to do!”

Ok, wow, a lot to unpack here. First off, typical software projects run over schedule, and most over schedule projects appear more done than they are. "The last 10% is the last 50%" holds far too often for software systems. So if we’re told a project is "almost done" that could mean it really is, that could mean it’s only 20% done, or the project could be at any point in between (usually less than 50% in our experience.) There are various software development methodologies Mighty Ant uses to manage projects and keep progress measurable and visible to avoid falling into the "it’s almost done" trap, but that’s another discussion.

If you crash this four times, we won’t drive it with you.

"Four other consultants have failed" is a very bad sign. One other consultant working on a project before we take it on is completely normal. We often take over development of systems done by internal staff members who made a start, made something useful, but over time the system grew too complex for them to extend, and they realized a high quality professional team could not only make the system work a lot better, but add things the internal team couldn’t. Sometimes we do project rescue, where the original development team is no longer available, and the system is either unsupported or troubled in some way. Sometimes we can shore those systems up, fix issues, then extend the system. Other times we need to redo the architecture from scratch -- but this situation is also common.

However, when four different consultants have failed on a system, then it starts to be like when you have an attractive friend that goes on lots of dates but "only meets jerks" and "can’t meet any quality people." If this keeps happening, at some point you realize that the one constant in the situation is your attractive friend. The "four developers failed" situation can happen when the first developer didn’t know what he was doing, made a mess of a system that looked in parts halfway decent, but didn’t actually work. The second development team was brought in to try to fix things, and they made some additions and changes, but also just weren’t up to the task. The third developer had a lot more skill. They worked on the system for a while until the realized it was fundamentally unsound and needed to be reworked. They then told the client how much it would take to do the system correctly. The client then fired the third developer for being too expensive (and stiffed them on their bill.) The fourth developer wasn’t even a developer, he was a salesman trying to sell the company on a prepacked system in their industry area, and he pulled a sales move and said his engineers would look at the customer’s incomplete custom system to confirm that the pre-made system did everything the client needed. But that didn’t work out so next our phone rings.

In situations like this we’ll take a pass. Taking over from one developer is normal. We’ve on very rare occasion taken over a project that two other groups have failed. But we’ve never been able to get a project off the ground when three or more groups have already failed on the same system. We’re particularly bemused when such a caller tells us our cost estimate is too much because it’s "more than twice what the other guys quoted us!" We’ve been actually told this. These would be the other guys that charged them money and produced nothing? (Heck, we could absolutely do nothing for half the price of the other guys if that’s the desired outcome.) The one time we came closest to working with a company that had failed with three different developers, where the project actually made sense, client management just couldn’t pull the trigger on the project because they didn’t have confidence that spending the money would bring them success (after all, they’d tried it three times before and failed!)

If your organization has failed over and over to build a software system, you have our condolences. While Mighty Ant DataWorks has never failed to deliver on our technical promises to clients in 29 years, industry-wide a bit over half of IT projects fail. So if we do the math, and you just get average technical teams, if half of projects fail, a quarter would fail twice, and an eighth fail three times (if they try a third time, most organizations only can stomach two failures.) So you’re not alone. But if you want to succeed, as we write on the home page, we suggest you call the right folks first.