If you need software that doesn’t just work for a while but for a long time…

Established small and medium-sized businesses have different goals than tech startups.

• Startups build a new product, knowing they’ll put it out to pasture after a few short years and start over.
• Their software engineers tend to reach for the latest, sleekest, shiniest tech stack. 
• The whole development environment is biased toward speed, speed, speed. 

We call this the “thoroughbred” option. 

A thoroughbred is exciting, and that’s precisely what our clients don’t need.

Our clients need software that will work well tomorrow, next year, and the year after that.

We call this the “workhorse” option.

Workhorse software does its job quietly, dependably, without too much kicking or complaining.

With the right care, the workhorse can have an extraordinarily long and productive life.

Over time, it makes you a lot more money than it costs you.

We build and maintain workhorse products for private, small to medium-sized businesses with greater than £1m in revenue. 

The SMBs we serve usually aren’t technology companies. 

Yet, they still need applications to automate certain tasks and processes and mitigate or minimise staffing costs.

They usually don’t have a CTO or in-house staff with the technical expertise required to support the application effectively. 

Yet, they still need a team of technical experts who think and act like business partners, not vendors. 

Foxsoft is that team. We give our clients a proven process to keep their apps working and proactively make them better. 

We turn applications from liabilities into assets.

Whether you work with our team or not, here’s what we recommend:

To build software that keeps working, you have to think beyond the project brief.

• What do your end users need the most?
• How will you handle stability and security?
• Do you have a quality strategy for your software?
• What’s your plan for keeping your application up to date?
• Are your developers working with a mender-first mindset?
• Software isn’t static, so how will you budget for support and maintenance?

Our founder, Andy Henson, used to work on the IT support and management side too. He spent many, many hours listening to end users complain rightfully about how poorly-built apps made their jobs harder.

If you want software that actually makes work and life easier, then you must work with the right technologies in an established ecosystem (e.g., Ruby on Rails). 

That way, you know it’s going to last a long time. It’s not a fad. Lots of developers will still be working with it five years from now.

Foxsoft brings a holistic, long-term, systems-oriented mindset to the products we build (and rescue). 

Once you finally commit to building software, it’s tempting to dive right in. How soon can we get started?! Maybe we could have a working version by the end of the year?

A product roadmap will help you pump the brakes (a little at least), ask the right questions, and ensure that you’re putting a Support & Maintenance First philosophy into practice:

• What is the minimum viable product?
• What is a reasonable budget and timeframe?
• How will you maintain health and minimize risk?
• How will you automate the entire development stack?
• How will you document the app to make it easier to work on?

Once development starts, an Agile Everything approach with short feedback loops will get you to honest feedback and improvements faster. 

To create a valuable asset, you must be in an investment, not an expense, frame of mind.

It won’t surprise you that software is like anything else. You get what you pay for.

As you find the right balance between up-front cost and long-term value, focus on the six ways the best Ruby on Rails development makes the value obvious:

• Full control of the software (aka, asset).     If you paid for the software, you should own it. It’s fine to give people you trust a spare key, but you, the client, should never have to ask for the keys to your own house.
• Clear, honest communication. You should expect your developers, who are fallible, to make mistakes and to quickly own those mistakes, not pass the blame. They shouldn’t keep making the same mistake.
• Client education. You want Ruby on Rails developers who can explain technical concepts to non-technical people without making them feel stupid. You want them to avoid corporate-speak, and depending on the day, you may need to speak with the project manager, product manager, or even the developer. The most direct and efficient communication should be encouraged.
• Frank but friendly pushback. You want developers who are friendly, personable, and easy to work with. But you don’t want “yes” people or order-takers. You want trusted advisors who will push back when they see anyone, including you, endangering a positive outcome. They can’t truly serve you if they varnish the truth.
• Sincere caring. This relates to pushback. You want “old-fashioned” customer care from pros trying to exceed your expectations. For example, at Foxsoft we have a “no broken windows” policy. We try to fix small things too, as we make our clients’ lives a little bit brighter each day.
• Transparent Pricing. Some problems are harder to solve with software than previously thought. The project scope (and budget) must evolve accordingly. Though this is normal, your development team should keep surprises to a minimum. The budget should be an open and ongoing discussion, not a black box. Transparent, predictable pricing from Day 0 to Launch Day and beyond is a must. Over the long term, support and maintenance cycles will comprise most of your costs. (That’s especially true if your software was poorly written in the first place.) Like your monthly insurance premiums, support and maintenance fees should be as predictable as possible. You can and should expect an excellent return on your investment through improved efficiencies and growth.

If these six facets of value matter to you, then start the conversation with us. 

Getting an up-to-date, reliable software product is one thing. Keeping it is another.

Thankfully, this isn’t as complex as it sounds:

• Treat support and maintenance costs as what they are—insurance—and pay your premium monthly.  
• Make regular upgrades to your system.
• Keep technical debt at an acceptable level and avoid the security, business, and financial risks that technical debt represents.

There’s no such thing as perfect software; improving the application can’t just be about clean code but achieving bigger business objectives.

We use the judgment gained from 20+ years of building software to know which bugs and issues are worth fixing and which ones aren’t.

We don’t enjoy talking ourselves up, but we thought it’d be helpful for you to know what’s important to us: