Let me make a wild assumption: You probably don’t want to replace your business applications every few years. You’d like to build applications that last. You want to build applications that grow with your company and adapt to changing technology.

The big problem: Technology is evolving faster than ever, which makes business application development even more challenging. If built incorrectly, a modern application today might be outdated in just a few short years. Obviously, businesses can’t afford to replace their applications every few years.

How can you build applications that remain relevant for years to come? How can you build applications that scale with your company and adapt to changing tech trends?

To help you answer those questions, I’ve compiled a short list of tips that will help you build applications that last. Now, I’m keeping this relatively high-level. We could write pages and pages on how to implement each point below. Rather than get into all of the details, here are the key aspects to consider when building applications for the future.

1. Start with the database

These days, implementing a simple database and building applications over that database is quite simple with the right software. The problem is–this means anyone can set up a database without paying much thought to its structure. If that application grows, the poorly-designed database will ultimately hold it back.

“The most important factor is a good database design,” says Luke Chung, President and Founder of FMS, Inc. “A design that scales over time as new data is added. Simply, ‘records are free, fields are expensive’. A design that requires changing table designs does not scale properly. Many software developers are not database experts and don’t realize the impact of time. Assuming the database is well designed, any technology that addresses the needs of the organization can be used.”

2. Architecture, architecture, architecture (Did I mention architecture?)

If you feel like I talk about application architecture a lot…you’re right. But, I do it for good reason. The importance of application architecture cannot be overstated. It doesn’t matter which technology you build your application around–you need a well-architected application if you expect it to adapt and scale with your company.

Tyler Wassell, Software Development Manager at mrc, explains the importance of application architecture: “When IT leaders look at their portfolio of business applications, they should be asking a few important questions: Can we move these applications to the cloud if necessary? Are they secure? Can they be accessed from mobile devices? Can we cost effectively maintain, modify, and customize them as our business needs changes? Do they scale? If the answer to any of these question is “no”, attention should be given to the underlying software architecture.”

Now, what if you aren’t experienced with application architecture? My advice: Find someone who is, or find a development platform/tool that handles the application architecture for you. The point is this: You cannot afford to skimp on application architecture. Spending time on software architecture now can reduce failures in the future. Whatever money you might save rushing through the architecture planning phase, you’ll lose many times over when you’re stuck rebuilding your application a few years down the road.

2a. Separate your architecture

Taking the architecture point one step further, K. Alan Robbins, CEO of Moose WorldWide Digital, explains that one key to building applications that last is “Tiered architecture, where the database, business logic, and presentation are loosely coupled. It costs a little more to build apps this way, but if done properly it enables the presentation layer to be changed without throwing out the entire application. For example, a business functional web site can be repurposed into a tablet application.”

I couldn’t agree more. Separating your application architecture into separate tiers dramatically improves its ability to adapt over time. How? Robbins touched on it briefly, but here’s another example: Suppose your applications are beginning to look outdated. With a tiered architecture approach, you can simply update the presentation layer with a completely new look and feel, without even touching the underlying database and business logic. Without the tiered approach, you’re stuck rebuilding the entire application.

3. Build for a platform that will last (Hint: It’s the web)

Can you say with certainty which platforms will exist in 10 years? I can’t. Maybe Windows will lose market-share. Maybe the popular mobile platforms (Android, iOS, Windows) will be replaced with different platforms. Who knows?

When I really think about it, there’s only one platform that I’m 100% sure will exist in 10 years: The web.

If you want applications that last, don’t tie them to a single platform. If you’re building applications for exclusive use on a single desktop or mobile platform, you put yourself at risk. What happens if that platform disappears, or a new popular platform emerges? The answer: Build web applications. The web is the only platform that works across any device and with any operating system…both now and in the future.

4. Build with an established language

Look, I get it. Developers love trying new technology. They love experimenting with new programming languages, frameworks, libraries, etc… When something new comes out, they want to try it. Frankly, I think that’s a great quality.

However, it becomes an issue when you start building business applications using a newer language that hasn’t quite taken off yet. What happens if that language never takes off? Then, you’re stuck maintaining an application built using a language with very little community support. What if it doesn’t work with future technologies? What if the language is abandoned due to poor adoption? While experimenting with new languages is fine, stick with established languages when building your business applications.

5. Avoid proprietary software/applications (use open source)

“When companies build proprietary applications they not only commit to high initial development costs, but they commit large amounts of resources to supporting and maintaining the application in the future,” says Gabriel Mays, Owner of Just Add Content, LLC. “If they don’t, it stagnates. On the other hand, open source applications are built, maintained, and supported by thousands of developers on a continual basis. Though some customization may be required, the bulk of the work is already done. The key is finding an existing open source framework or platform that fits the problem.”

I’d like to take that thought one step further: Avoid any path that ties you to a single vendor. For instance, some companies opt for development tools that create proprietary applications, which cannot be maintained outside of the software. This limits their future options, and ties their success to the success of the tool vendor. If you do choose the development platform/tool route, opt for a solution built on an open foundation that lets you maintain your apps outside of the software.

6. Build in flexibility

Let’s face it: You can’t possibly predict how technology will evolve, or which new capabilities your company will need over the next few years. However, with proper planning, you can leave the door open for new features down the road.

“Most software apps become Frankensites/Frankenapps because they get so many tools and functions added to them down the road that their appearance and usability suffers dramatically,” explains Jeff Kear, Owner of My Wedding Workbook, LLC. “When you are first scoping out your application, try to brainstorm all the potential uses that the software may have in the next 5-7 years. You probably won’t add many of these tools upfront, but if you have figured out a potential home for them in the application and built the framework so you can somewhat easily integrate them after the fact, then you won’t be kicking yourself down the road.”

Wrap up

With technology evolving at break-neck speeds, building applications that last is more difficult than ever. How can you build applications that scale with your company and adapt to change? While you can’t truly plan for everything the future might bring, the tips laid out above will set you well on your way to building applications that last.

What do you think? Did I miss anything? If so, I’d love to hear your thoughts in comments.