Tag: Methodology

Categories
Community

Calling All Developers to Shape the Future of Software Development

shape the future of software development

The latest Developer Economics survey is now live, ready to measure the pulse of the developer ecosystem, helping the world understand developers and vice versa. We are calling all developers to shape the future of software development.

Here are a few facts about our developer surveys:

    • This is the 17th edition of the semi-annual Developer Economics surveys.
    • It is supported by the leading developer communities and technology vendors around the world: Amazon Alexa, Azure, ARM, Connected London, Intuit, Here, Digital Ocean, Nutanix, DZone, Hacker Nest, Heroku, Intel, Microsoft, Mozilla, Pivotal, VMWare, Salesforce, Samsung, SAP, Sitepoint, and more. However, it is run by the independent analyst firm /Data. (https://www.slashdata.co/)
    • We reach over 40,000+ developers in 167 countries annually.

Who is this for? Who will shape the future of software development?

Software developers of all profiles including professionals, hobbyists, and students who work across all major areas: mobile, web, desktop, cloud, IoT, AR/VR, games, machine learning & data science.

What has changed in the survey?

  • We have redesigned our questionnaire to capture all trends & insights related to the developer ecosystem.
  • Developers can now sign-up for a global, independent, ever-growing community.
  • We have a new Point System. Developers can earn points through several actions and unlock exclusive content and prizes.
  • The survey theme. It’s now easier to walk through the questions with minimum distractions. That said, we try to make the survey taking as fun as possible, so that survey participants can enjoy a few fun facts throughout their experience.
  • We want to hear the true developers’ voice so we reward them with amazing prizes, gadgets, licenses, etc.
  • For each completed response to the survey, /Data will donate USD $0.1 to the Raspberry Pi Foundation to support the developers of tomorrow access tools and learning courses.
  • There is a revamped Referral program available for all survey takers. Sharing is caring!

& What has stayed the same?

  • It features questions that cover developers’ level of coding skills, favourite programming languages, technologies used for work/hobby, go-to spaces for learning and resources, as well as preferred tools for specific areas of development: mobile, web, desktop, cloud, IoT, AR/VR, games, machine learning & data science.
  • We still care about learning and giving back, on top of helping devs
  • Available to developers around the world in English, plus 8 other languages: Chinese Simplified, Chinese Traditional, Spanish, Portuguese, Vietnamese, Russian, Japanese, Korean.

For any additional information regarding the Developer Economics Survey, feel free to contact the Developer Economics team at community@developereconomics.com.

Developer Economics survey is now open, inviting all developers to take the survey and voice their opinions about platforms, apps, languages, APIs, revenues, dev tools, and more.

Are you a developer? Have your say!

Join us today!

Categories
Tools

Cross-Platform Tool Trends – Freemium & Flexible

CPT trends

CPT trends

Creating versions of an app for multiple platforms (at least iOS & Android) is an increasingly common requirement. Building and maintaining native code for every platform supported is both difficult and expensive. Cross-Platform Tools (CPTs) offer a solution to this problem by enabling sharing of code across platforms and in many cases a single code base can target multiple platforms. With such significant cost savings available, why don’t all developers use CPTs?

Learning curves & licensing

Unfortunately the platform spanning magic provided by CPTs doesn’t come without any costs. Most CPT vendors depend on licensing revenue – developers have to pay to use the tools. Of course the cost of licensing most of these tools is far less than the cost of a full native port of an app to one additional platform. However, there are more costs associated with adopting a tool than the license fee; learning to use a CPT and building confidence in it’s suitability for future projects requires a significant time investment. The potential future cost of switching away from a tool that isn’t working out as hoped is also something that developers must consider.

The spread of Freemium models

In order to build sufficient confidence in a CPT to build their businesses around it, some developers need lots of time for evaluation, perhaps building a side project before risking major apps or customer projects. For many the 30 day trials that were typical in the sector just weren’t sufficient. One of the first mobile CPTs, MoSync, was very early to recognise this and had generous free options early on, they even went open source with a dual licensing model back in 2009 around the time many of their competitors were just launching. This year has seen a tipping point, possibly partly due to increased competition in the sector but also to capture a larger share of the ever growing demand for mobile development – Appcelerator, Corona, RunRev, Unity and Xamarin have all either switched to freemium models or expanded their free offering for mobile. RunRev has also joined MoSync in releasing their code under an open source license, Appcelerator have open sourced more of their code and Xamarin have just open sourced some of their cross-platform API wrappers. Having access to the code for the cross-platform layer can help remove developer fears of getting blocked by a bug in their chosen tool and being entirely dependent on the vendor for a rapid fix.

Technical tradeoffs

In many areas platforms are sufficiently different that it’s not possible to unify them under a single API. CPTs get around this in a number of different ways:

1) Not providing access to the problematic functionality – this restricts what developers can create.
2) Providing a lowest common denominator API – this prevents developers from using the full power of the native platforms.
3) Providing their own implementation of the functionality – this can bloat apps and often prevents them from having a fully native experience.
4) Providing thin wrappers or separate extensions for each platform – this gives maximum control but adds complexity to the code, reducing the benefits of a cross-platform approach.

Different apps, or even parts of apps, will have different priorities that determine which of the above approaches are acceptable. For example, a mass market consumer utility app is likely to require a completely native look and feel for the UI, while an internal app for a large enterprise may want to look and feel exactly the same on all platforms to minimise both development and staff training costs. The same tradeoffs won’t always apply to every part of an app either; most games have a completely custom UI and don’t require access to the native platform UI components at all, however, they may well want access to the new Google Play game services, or the iOS 7 Game Controller APIs as soon as they are available.

A flexible future

Faced with a still growing list of platforms to support and wide array of new features in each new platform version, CPT vendors now have to specialise for a sufficiently profitable subset of the market that has fairly narrow requirements or become increasingly flexible. Most vendors currently provide flexibility through a native interface that enables the creation of third party extensions or plugins. Xamarin’s approach to flexibility enables developers to (semi-)automatically generate wrappers for any native API or library, which is ideal for developers who want to stick with C# for all of their own code yet build on the work of native developers for each platform.

Even greater flexibility is possible though. What if you could just build the parts of an application that made sense to be cross-platform with a CPT? RunRev has a beta for an embeddable library version of their engine to enable this, although currently only for iOS. They are also re-architecting their engine to put 3rd party extensions on an equal footing with the core functionality – even allowing them to extend the language where necessary. Another interesting option going forward here is Digia’s Qt, the open source cross-platform framework that was acquired and re-purposed for mobile by Nokia before they dropped it in favour of Windows Phone. Qt is now the native framework on BlackBerry 10, Ubuntu Mobile and Sailfish OS and is close to production readiness for iOS and Android; it also has a Tizen port ahead of the release of that platform. The core of Qt being C++, it can easily interface with native code on most platforms and has always been delivered as a library, so it’s also embeddable within native apps.

Flexibility enables greater agility

This library format means that developers can start cross-platform and add or optimise parts of their app with native code later. It’s possible to just add a full native experience for the platforms that get the most traction. Alternatively, starting on a single platform and then adding new functionality that works across all platforms after achieving some success and starting to port to other platforms is also an option. Last but not least, the library format also removes any concerns about lock-in. If a developer decides to migrate away from a CPT, they can do so gradually, without having to port/re-write everything in one go. It’ll be interesting to see how many vendors can push flexibility this far and how many developers take advantage of it.

Categories
Business

Prototyping: needless effort or driver of perfection?

Mobile apps are becoming more and more sophisticated every day. They evolve together with mobile devices, giving us even more pleasant, intriguing and unique experiences. Design, usability, functionality accompanied by various touch interactions, animations, and transitions are integral components of apps.

Building an app is not easy. It involves various stages in a long development life cycle. Apps require time to build, time to test, and time to iterate for improvements. Iterations are not easy especially when extensive code changes are required and that’s where usually things get messy.

There is one solution to avoid the trap that lies ahead when developing apps: prototyping. A prototype is an early sample or model built to test a concept or process, or to act as an object to be replicated or learned from. The prototyping step is often skipped due to the extra cost and effort it adds to the lifecycle of a project. However, it is widely accepted in the development world today, that undermining this vital part of the design and build process may lead to miscommunication between developers and clients, pitfalls, over budgeting, and bad quality products. Prototyping allows developers to conduct proper user trials, iterate before coding and send the app to production only when it is perfected.

Graphic designers, user experience designers, usability experts, interaction designers, and developers use different ways and tools to create prototypes. The most popular methods used for prototyping apps are paper prototyping, presentation software, mobile apps (usually for tablets) designed to allow people to prototype mobile applications on actual mobile devices, source code and prototyping applications and tools either web (offered as SaaS) or desktop apps.

In the following section I will briefly describe the prototype tools vendor landscape and the main needs that these tools serve.

Vendor landscape

If we ignore for a moment the paper prototyping and source code, where no specific tool is used, then we are down to three main types of prototyping tools: presentation software, mobile apps and mobile prototyping applications.

prototyping-tools-landscape

Presentation software like Keynote or Powerpoint, are in the market for decades and peeple are well trained to use them in different ways. The way people use them for prototyping, is by linking sketches, or design comps together in a presentation since such tools support animations and screen transitions. Some UI libraries like Keynotopia have UI components of popular mobile operating systems like iOS and Android, designed for presentation software. Presentation software are built for an entire different purpose and they are limited in prototyping functionality but are still valid in some user cases. Diagramming software like Omingraffle and Gliffy are sometimes also used for prototyping.

Mobile apps for iPad and Android tablets designed for mobile prototyping allow real device testing which is their main advantage. Some of these apps provide UI libraries of major mobile UI components like App Cooker and Interface HD. Others, like Popapp allow taking photos of sketches and linking them together. Most of these apps are limited to single device prototyping and usually lack sharing and collaboration tools but are very useful when it comes to quickly validating an idea.

Mobile prototyping applications are web or desktop applications designed specifically for mobile prototyping. These applications vary from simple traditional wireframe applications (including mockups) to advanced prototyping tools that are able to provide a varying degree of mobile-specific functionality such as touch events and gestures, interactions, screen transitions. Most importantly these tools provide the ability to preview a prototype on the actual device.

There are three different types of such mobile prototyping applications:

  1. Hotspot apps are usually web apps that allow you to upload your mobile design comps and link them together usually with a single event (click or touch) without (or at best simple) transition effects. These apps are useful especially for collaboration as most of them allow comments and annotations. Although some of these tools make real device preview possible (i.e. preview on the actual device that the app is built for), they are not really eligible for proper user trials as they do not allow multiple interactions such as touch gestures and other important mobile specific features. Applications in this category are Fieldtest app, Invisionapp, Popap and are usually web apps offered as Software As A Service or mobile apps for tablets and Smartphones.
  2. Wireframe or Mockup tools are tools that allow the development of still wireframes or mockups. Usually these tools have a large number of UI components libraries available. Some of these tools have been in the market for years as they were designed for website mockups or wireframes, but many of them have been changed in an attempt to embrace needs specific to mobile apps. Many of these tools are very advanced in functionality and features, offering a range of useful companion tools for collaboration and more. Most of these tools are limited to single tap interaction (or mouse interactions, as they are designed for web sites) and no or limited animations and transitions. Tools that fall under this category include Balsamiq, MockingBird, UXpin, Pidoco and others and they can be found as web apps available on a subscription basis or as desktop apps.
  3. Prototyping tools are web applications or desktop software designed from the ground up and specifically for mobile (or web) prototyping. These applications go beyond traditional wireframe or mockup applications, to provide functionality for mobile touch events and gestures, interactions, screen transitions and most importantly provide the ability to preview a prototype on the actual device. Many of them come with UI libraries for iOS, Android, Windows mobile and Blackberry and offer collaboration tools and functionality. Tools and software in this category include Axure, Indigo Studio, Proto.io and many more.

[sectors slugs=’prototyping-mockup’]

Current challenges with prototyping tools

Prototyping tools are still in their infancy. They have been around for two years or less must be in sync with the ever changing mobile industry. New mobile devices become available on a daily basis, new versions of mobile operating systems and new functionality that needs to be supported makes the chase even more difficult. The main challenge is the ability to test the prototypes on the real device. In order to achieve this more tools render their prototypes in HTML5 so that they can run on a native mobile browser without the need of installing and maintaining various mobile apps.

Another major challenge is performance and by using HTML5 features such as animations render much slower on a mobile browser than they would on a native app, making the experience a bit far from real and as such defeating the purpose of doing a full prototype in the first place. Nevertheless, some of these tools have reached a maturity level that allow professionals to create fully functional, interactive mobile app prototypes of their apps that look and behave exactly as their app would. This allows the teams to conduct user trials, gather feedback, and iterate for improvements. Furthermore, a proper prototype narrows the communication gap between designers and developers (coders) as well as with the app team and the stakeholders.

Future opportunities with prototyping tools

Prototyping tools gain larger audiences as mobile technologies progress. As mobile apps become more sophisticated, more detailed prototyping is required. The mobile market grows and the prototyping tools market will continue to grow with it as more Operating Systems and newer more capable devices are released. New devices come to life every day, from car navigation systems to refrigerator panels, all having in common touch and interactive interfaces.

Categories
Business Tips

How to Optimise Ad Revenue

Optimise Revenue

On the surface, advertising seems like a fairly simple and easy to implement business model for an app. Decide on some places to display ads, integrate one or more third party ad services and wait for the money to start rolling in. If you do this without a clear plan for how and why users will interact with ads in your app you’ll probably find the revenue disappointing. Optimise revenue by growing your user base, increasing engagement and improving your fill rate (how many of your possible ad slots actually show an ad) and eCPM (effective cost per thousand impressions). The challenge becomes apparent when you try to improve these metrics and find them somewhat opposed to one another. Show too many ads and users either use your app less or abandon it altogether. Make the ads smaller or display them less prominently and your click-through ratio (and hence eCPM) goes down. Show a lot of irrelevant ads (higher fill rate typically has less relevance on average) prominently and users start ignoring all of them by default. Make your ads prominent and they’d better be relevant. If it’s hard to target your audience well then keep the advertising low key and count on volume to make up the revenue. It turns out that getting the right balance is very difficult and not many developers manage it.

Higher eCPM != higher revenue

A very small fraction of developers in our survey managed to achieve truly exceptional eCPM’s, greater than $5, sometimes even more than $10. These developers were almost all making multiples of the average revenue in total but they were also using more than one revenue model. It’s likely that most of their revenue was coming from another source and they showed very few highly relevant ads to get those rates. If we focus on the developers who only used advertising as a revenue model then those with eCPM’s below $0.25 were earning significantly more on average than those with eCPM’s from $0.25-1.50. So, for the majority of developers, those with higher eCPM’s make less money. To add to the confusion, size of active user base is also very weakly correlated with ad revenue; the simple concept of getting more users to make more money from ads doesn’t work on its own either.

Why iOS developers make more with ads

A good illustration of the complexity is to compare iOS and Android developers. As reported by several ad networks, iOS gets a higher eCPM on average than Android. However, our survey data suggests that the difference is all at the very high end. If we exclude the developers with eCPMs over $5, iOS actually has a lower eCPM than Android. For those only monetizing via ads, Android developers had a 37% higher eCPM and while the iOS developers only had 20% larger user bases on average, they earned almost 75% more revenue every month. This suggests that the iOS developers were seeing very much higher engagement with their apps and thus delivering many more ad impressions.

The fallback network fallacy?

There’s some popular advice that in order to maximise ad revenue, developers should use at least two ad networks, one with a high eCPM and low fill rate and another with a lower eCPM but very high fill rate. The theory is that this ensures they get the most relevant targeted ads with the best rates when they’re available but still don’t waste the inventory by filling it with less relevant lower paying ads when they don’t get filled by the premium network. This fallback strategy sounds logical but does it work? There’s some possible support for this in the fact that developers using more than one ad network make slightly more money on average than those who only use one (and 70% of developers purely monetizing through ads only use one network). However, this seems more likely to indicate greater sophistication than successful use of the fallback strategy. The ads from the two different networks are unlikely to fit the same presentation, positioning and format within an app well. There’s some fairly strong evidence against this fallback strategy within our survey data – developers with eCPMs above $5 are excluded from the following sample and so are those earning greater than $50k per app per month in revenue due to the disproportionate effect both tiny minorities have on averages.

Note that 67% of developers using ads selected neither eCPM nor fill rate as reasons for choosing their ad networks and that percentage is mirrored in the group only using ads for monetization. Those that selected one criteria or the other but not both generated slightly higher eCPM than average and significantly higher revenues. Developers trying to maximize both metrics to squeeze the maximum possible revenue out of the advertising space in their apps generated the highest eCPM but did far worse than average on revenues.

Optimise for engagement

This data suggests that developers should pick an appropriate advertising style for their app and try to go for either quality or volume of ads displayed but not both. Considering that the most popular advertising services use a cost-per-click model, the highest eCPMs are likely to simply reflect higher click-through ratios. In many cases the taps on ads may be accidental. Ads getting in the way of the content or usage of an app result in fewer users or lower usage and thus lower revenue. It seems that by far the best way to optimise ad revenue is to build app experiences that people want to spend a lot of time using and make sure the ads don’t spoil them. The extra volume of impressions generated by tens or hundreds of thousands of engaged users will more than make up for lower eCPMs or ad inventory not getting filled.

Categories
Business

Why Measurement Matters – the case for analytics

Measurement Matters

Creating a successful app business takes a lot more than a good idea and the skills to develop an app and upload it to a store. As we’ve discussed before, developers who promote their apps are almost 3 times as likely to break-even as those who don’t. This is the simplest difference with a massive effect on success. It seems obvious, no marketing means a good chance almost no-one discovers the app and thus no revenue, yet some developers still don’t do it. Picking the most lucrative platforms seems like another obvious candidate; considering only those developers who are interested in making money, those that develop for iOS are a little less than twice as likely to be above the “app poverty line” (38% earn over $500 per app per month) than those developing for BlackBerry (20%). Getting your revenue model right can also make a significant difference; according to our survey, developers using a subscription model earn nearly 2.5 times as much as those using other revenue models on average. Not all apps can use a subscription model, however, there is something that almost every developer can do which is correlated with more than double the chance of being above the app poverty line and earning more than 2.5 times the average revenue compared to those that don’t…

Measuring user activity and crashes

You managed to build an app and get people to download it but how many of them still use it? When do they use it and how often? What devices do they have and which firmware versions? What features do they use the most? Which parts of the app should you focus on improving? Do your changes to the app make users interact with it more or less? All of these questions require measuring the user interaction with the app by recording data and analysing it. Unless your app regularly interacts with your own backend service which you can collect relevant statistics from then this would be an expensive capability to build. Fortunately there are a number of third party usage analytics services to do it for you and the two most popular, Google Analytics and Flurry, are free to use.

Similarly, no app is perfect when it is launched and it’s almost impossible to test on every device and firmware combination out there in the market. If some of your users are getting crashes that you can’t reproduce and fix quickly then you’re likely to get a lot of poor reviews, which will reduce the chances that other users download your app in the future. Unless you have tooling in place to capture details of crashes and report them to you then it’s very hard fix them. Although there are libraries that can report crashes to you directly, unless you want to analyse every single one manually, you’ll want tools that do that for you and categorise them such that the ones with common causes are grouped. Without this there’s no good way of prioritising what to fix. Again, crash analytics & bug tracking service providers can handle this for you and one of them, Crashlytics, was recently acquired by Twitter and now provides all of its features for free. Other providers also have free tiers.

This is not to suggest that the free options are the best for every app, just that there’s very little excuse for not using these tools because there are free ones. If you need convincing, take a look at this infographic, which uses our survey data for just the respondents that were interested in making money and earning less than $50k per app per month (we exclude the very small number of top earners as they can distort the stats, although in this case they would only make the argument stronger).

Correlation is not causation

It’s really important that we note a strong correlation between usage of analytics tools and increased success for developers only. Correlation is not causation. It’s clear that simply integrating these tools and doing nothing with the data is not going to make the slightest difference to anyone’s results. They are trivial to integrate but provide no direct end user benefit at all and no additional revenue stream. It could be argued that most providers only make these services available for the leading platforms and the extra success is primarily due to that. This is not the case – restricting the data set to those developers whose primary platform is Android or iOS produces an almost identical pattern of results. Another argument is that crash analytics services are typically focussed on native stack traces, which don’t often provide much diagnostic value for non-native apps. However, anyone tempted to blame a poorer non-native user experience produced by development tools that are also less likely to support these analytics tools should note that cross-platform tool users make more revenue.

One valid argument is that until you have a successful app with a fairly large and diverse user base, collecting crash data and analysing it is not the biggest problem you need to solve, those who use the services may simply be the ones already big enough to have the problem. There are two arguments against this. First, integrating crash analytics after you’ve acquired a large user base is too late; how many users will give you a second chance installing at least 2 updates to a crashy app (you can’t fix it until the update after you integrate the analytics)? Second, this doesn’t explain why those integrating both types of analytics tool have a significantly greater chance of being above the poverty line than those that only integrate one or the other. Similarly, whilst there is almost certainly an experience factor at work here it is clearly not the whole answer.

The most plausible explanation for these results is that those with a more scientific approach to their app business tend to collect as much data as they can and use it to drive decisions about their development. This produces more successful apps than intuition and guesswork. So, sign up for analytics services, integrate them with your apps and act on the data they provide. This process can’t magically turn a bad idea or unwanted app into a success but it can help make a decent app into a much better one. If you apply some of this data-based reasoning and scientific methodology to deciding what to build and how you market it too then that’s likely to further increase your chances of success.

Got an alternative explanation for this data? Let us know in the comments below.

Categories
Business

How to Get App Ideas

How do you decide what app to build next? Paul Graham wrote an excellent post about the related problem of finding an idea for a startup. Paul says:

The way to get startup ideas is not to try to think of startup ideas. It’s to look for problems, preferably problems you have yourself.

The very best startup ideas tend to have three things in common: they’re something the founders themselves want, that they themselves can build, and that few others realize are worth doing. Microsoft, Apple, Yahoo, Google, and Facebook all began this way.

However, it should be noted that when Paul Graham says “startup” he does not mean any new company, only the hyper-growth variety that are often funded by venture capital. It should be noted that the vast majority of these companies fail. So, if you’re building a business around apps and are aiming your sights a little lower than “the next big thing” then our survey suggests that solving your own problems might not be the best option. 49% of developers build apps they want to use themselves, but end up generating the least revenue.

Beware survivorship bias

The following data should be interpreted carefully, some of the most successful strategies are only viable for larger publishers, or only available for those who already have a successful app – this creates survivorship bias. However, there appears to be a strong correlation between more carefully researched methods of deciding what app to develop and financial success.

Developer Economics 2013 - Successful developers grow by extending apps into countries and verticals

Business side of apps is harder than the technology

Almost half of developers (49%) in our survey decide which apps to develop based on their own needs. Those same developers end up generating the least amount of revenue per app per month, indicating that they have a lot to learn in how they plan their app business. Naturally, planning a business based on own needs may yield a good customer understanding, but lacks the rigor of market research or of extending proven app recipes into new countries or verticals.

User feedback is effective but hard to get

We find it remarkable that only 24% of developers in our sample plan their apps based on discussions with users, a figure which does not change with development experience or proficiency. This indicates that the bottleneck of the build-measure-learn cycle of lean development is the “measuring”, or listening in to user needs. This highlights the need for a frictionless 2-way feedback channel between developers and users, much like what GetSatisfaction pioneered for web apps, and which now HelpShift is pioneering for mobile apps.

Market research pays off

To decide which apps to build, a sizeable share of developers uses market research and competitive intelligence. Market research and competitive intelligence are well-established practices in business development and we expect that the increasingly business-savvy developer population will, in the near future, invest more effort in these elements when designing a product strategy.

Bigger publishers have more options

Developers that publish more apps per year tend to make decisions based on different criteria than those publishing only a few apps per year. For developers publishing 16+ apps, the decision mainly lies with clients or management – these are mostly professional developers that work on commissioned apps or as employees of larger publishers where the decision on which app to work on is mainly based on a defendable business case. Developers publishing more apps also tend to rely on market research more, whether that is purchased research or own research through app store monitoring and analytics services.

Build on success

The most successful strategies are those that extend an app into markets, either into verticals or different geographies. To some extent these strategies rely on an already established and successful business: these are apps that have been tried and proven in at least one market and are generally less risky options or “low hanging fruit” for developers.
[doritos_report location=’DE13 Article – App Ideas’]

Categories
Business Tips

Crowdfunding: Leanest Way to Launch?

crowdfunding

One question that divides opinion among developers is when to start marketing your app. Some say if you start marketing too soon, the early interest you create will dissipate before you actually have something to sell. Others argue that you can’t start talking about your app soon enough, build a following of early adopters and you have great word of mouth marketing and an initial sales boost to climb the store charts. What if you can have the benefits without any of the downside? It might just be possible with crowdfunding.

Continue reading “Crowdfunding: Leanest Way to Launch?”
Categories
Business Platforms Tips

The Developer Platform “Lean Factor” and Why It Matters

lean framework

There’s a lot of buzz about Lean Startups in the software community in general and amongst mobile developers in particular. How lean a startup can be is strongly influenced by the tools and processes available on their chosen platform. Which platforms enable the leanest product development processes? How and why does lean framework matter?

Continue reading “The Developer Platform “Lean Factor” and Why It Matters”