The most convincing argument I ever heard for why organisations should not go down the road of building apps is because once they build it they in effect become app developers. From that point on they need to manage the updates for two operating systems, manage bugs, feedback and changes, and unless they want their app to stagnate, update and release new features. Like many web and digital builds often an organisation only finds funding for the original concept. That’s mostly the fun bit — build something new, learn, create, share. The difference between a web build and an app build however, is where websites can be iterative can you can add content and features overtime, apps will require you to have inhouse developer knowledge or lean much more heavily on a developer for content and function changes. There are a lot of ways to build apps and a lot of technologies out there. The chances of you building something that another developer finds very difficult to unpick and make changes to is high. In tech, you aren’t paying for software (well in open source tech), you are paying for time. Time shouldn’t be undervalued, and complicated things, bugs, new features, and mistakes take time. Enterprise and organisations are increasingly looking to digital as part of their offering, and why would you not? But the minute you start building you become a digital product developer, it’s your job to build, support and maintain that product. You are responsible for the privacy and the security of the data that users trust you will keep safe when they upload. Going “agile” and prototype and releasing early may have great appeal, but how will you support those earlier versions? Or are you just going to export the data out and import it into a future stable version? These are questions we ask when we manage developer teams and product development. Whether you are building an app or a websites, once you start to get a mass of sites under your umbrella — or you want to build products to sell — the choices you make and how you set up your platform will impact you and others for a long time. Last week I had an interview with a large corporate looking for a Drupal developer, they need to migrate 16 Drupal 6 and 7 sites into Wordpress. Two years ago the manager was hired and started looking at platforms. They have a distributed set of brands, and they found their brand managers knew Wordpress so they chose this as their platform. Ok. Except they need the functionality and look of their sites to work exactly the same as it does now. In my experience it’s much quicker and cheaper to rethink than to replicate. The most concerning part was their concept of putting in a user access function over the top of wordpress to restrict role function and access to pages. User access is complicated in systems, when its a function within the system core it’s a-ok, when you need to start using add ons it gets messy. I’ve used Drupal user access tools that have conflicted with each other, and the management and implementation of user access gets messy. Underlying this is the problem that managing 16 websites is a considerable technical debt regardless of the technology. A core concern I have in this case will be that the user access function will restrict their ability to take advantage of Wordpress’ auto update function. They have swapped one set of technical management issues for another. At some point in the future they will have the exact conversation they started two years ago. There is little you can do to sway a decision on technology, especially not once a manager has spent considerable time and energy doing their best to assess within their capacity. Actually, made me think of this tweet… My advice to them (essentially) was that they did not need a Drupal developer, they needed an excellent WordPress developer and a person with content skills that could help with the manual transfer they needed. It’s going to be a tedious project, and that’s ok, lots of tech projects are tedious, but bringing in an over qualified developer to any project just busts your budget and minimises the chances of them sticking out the job. And also it needlessly tarnishes a platform like Drupal which from this point on is considered even more expensive and costly. Now I could have talked to them about taking a product approach to building out their Drupal sites. I could have explained how they could create a system that allowed them to replicate and roll out new sites, and create features that could be shared within their sites. After all their brands are going to grow, evolve and change, because that’s the nature of their business model. I could have also explained that Drupal can be locked down with user access and we can simplify the editing interface so that managers felt comfortable with it. But once the decision has been made it’s difficult to get people to budge in my experience, however technology is actually a long game and I would consider this a winnable client in the future. Especially if a distribution or model was created specifically for this industry’s needs. Technical debt, continuous improvement and updates, and how you will structure your developer team and futureproof the development process is critical to not only developing a digital product you can share or sell with other communities, it will be critical to the financial viability and sustainability of the product, and therefore your organisation or business. Next time you chat to a tech person ask them about their experiences managing different technologies and platform versions, if they start ranting stake stock, if they tell you it’s easy run for cover! Lyndsey builds, creates and connects people, places and things using technology. She’s a community girl living in a digital world. e: t: lin: hi@lyndseyjackson.com.au Lyndsey lyndsey-jackson www.lyndseyjackson.com.au
![Guide to 24 PHP Frameworks [Part 2]](https://hackernoon.imgix.net/hn-images/0*48nyAqGzXwKodd6h.jpg?auto=format&fit=max&w=3840)
