Are you thinking about developing the next great mobile app? When creating your business strategy you’ll want to know:
- How many potential app users there are?
- What platform you should develop for?
- What apps have the greatest reach?
- What apps generate the most revenue?
The mobile app market is evolving quickly, so the answers to the above questions change frequently. In this blog post, I will report the most recent numbers, and also provide links to resources that you can use to stay up to date with the information you need. Read more on Developing a Mobile App? Some Numbers You’ll Need to Know…
This post is revised and republished from Carl’s blog at Crain’s Detroit Business.
How should you build your next innovative product or service? One major consideration is whether to do the work inside your company or outsource it. I’ve identified some key dimensions of this problem to help you think through your choice. I’m assuming you have a project large enough to need at least a small team of people, that the stakes are high for you and your company, that time-to-market matters, but is not the overriding factor and that your company is large enough to have employees to consider using. Read more on To In-source or to Out-source? 9 Questions to Ask Potential Teams…
So, you have decided to sell software. Congratulations, you are now a software company!
Maybe your building the next big new product that is going to change the world, or perhaps you are re-purposing an internal piece of software that has really helped your company. Either way, it doesn’t matter. There is a lot of strategy and implementation work that needs to be done (maybe more than you realized!).
Read more on Creating a Software Company? 9 Decisions You Have to Make…
You come up with a great idea for an app, and you’re sure it’s going to sell! You plan to have it built and in all of the app stores in a few months — soon after that, you’ll take a vacation or retire on your vast app income. The app, the idea, and the marketing plan will all just form as you go and everything will be perfect.
Wrong! Most of the time, the first idea is never the final idea. It takes work. Read more on Your App Idea Stinks! 3 Steps to Make it Better…
Atomic’s success ultimately depends on our client’s success, and their success turns on much more than the quality of the software we build. This drives a lot of our business decisions:
- We brought design practices and designers into Atomic back in 2007 to help our clients determine the right thing to build.
- We start every project by digging into the business ecosystem and our client’s business goals — that understanding helps our teams contribute valuable new ideas and guides development priorities.
- We’re as diligent with deployment and hosting as we are with programming and design.
- We offer beneficial support agreements.
In short, we take a broad view of what’s necessary for market success and provide help well beyond programming. Read more on The First Tech Hire – Helping Clients Build their Software Company…
If you or your organization is ready to invest thousands of dollars on building a piece of software, you hopefully already have a good idea of who your users are and how they will interact with your product. You could be a subject matter expert, or your company may be a leader in the field that your project is targeted towards, putting you in a great position to provide background on what the software ought to do and how it should be used. What you’re looking for is a top-notch team ready to hit the ground running and build your software.
In a previous post, I discussed how Atomic Object engages with our clients in a phase of Research, Design, and Planning (RDP) at the beginning of each project to help define and refine a software product. If you’re well-prepared and grounded in your field, it could be difficult to see how this work could be worthwhile for your project, and skipping RDP may seem like a great way to save some money towards feature development. However, just a bit of time up front can pay off in a big way during the build phase of your product. Here are several ways an RDP phase can benefit a project. Read more on Strengthen your Software Investment with Research, Design, and Planning…
Surgeon Simulator 2013
Let’s look at a hypothetical situation. You have a medical issue requiring surgery. While there are many surgeons that could get the job done, each one has their own level of ability and skill. Through their choices, the surgeon will affect overall “quality” of the operation — which procedure is used, cosmetic results, general odds of success, and how any unforeseen complications will be dealt with. The surgeon won’t have a complete picture of the situation until the operation is underway, and even then surprises are possible, so overall skill is essential.
If faced with this choice, how do you determine which surgeon to hire? It’s not easy when risks are (potentially) high and your technical understanding of the field is low. Your choice could have a potentially dramatic effect on the outcome, and there’s no going back.
I imagine that this is very similar to how it feels to be tasked with selecting a firm to develop custom software for your business.
Read more on Beyond Domain Experience – 3 Qualities of Great Software Teams…
One of the traditional problems in software development is the delivery of a finished project. Atomic Object writes custom software, but we ultimately need to deliver it to our customers, which usually implies deploying it to an existing infrastructure environment, or handing it off to an operations team.
Unfortunately, this hand-off process often introduces a variety of glitches and bugs due to differences between the environment that the software was developed in (the development environment), and the environment it will actually run in (the production environment).
Vagrant is a tool for creating and configuring virtual machines. It provides an interface to easily bootstrap and manage virtual machines using a variety of different virtualization platforms and configuration management tools, both open source and commercial. By using Vagrant, developers can easily write and test applications in environments similar to which they will actually be deployed. This reduces the likelihood of glitches and bugs when handing off a finished project to customers. Read more on Why Vagrant? – Preventing Deployment Issues from Day One with a Virtual Machine…
Human-Centered Design (HCD) practices help companies develop innovative product concepts. From my experience, extending HCD practices inward to include a company’s information technology team increases the chances for success.
What is Human-Centered Design?
IDEO (a leading global design consultancy) recognizes that HCD involves viewing solutions through the lenses of Desirability, Feasibility, and Viability and building products that live at the intersection of all three lenses.
Read more on A Human-Centered Design Approach to Involving IT in Product Development…
When you are developing initial requirements for a new software product development project, you may find yourself questioning the appropriate level of detail to provide for specifications.
You may feel compelled to provide a high degree of specificity so the development team can create an accurate estimate of cost and time to build the defined solution. You may feel worried that if you miss something in the software requirements, the project — or even you — may be viewed as a failure. The good news is that you can loosen up! There is a better way to develop requirements, and it doesn’t include specifying every detail at the start of the project.
Detailed Specifications – Too Much Definition, Too Soon
The first step is to realize you probably should not be creating a detailed set of functional or technical specifications for a development team to build. It’s usually too early to focus on detailed specifications before the development team has an opportunity to creatively engage in the project at a broader level — including business and user motivations. Providing detailed functional and technical specifications too early can create a false sense that the problem or opportunity is completely understood, which can result in missed opportunities or inaccurate project plans.
Read more on Creating High-Value, User-Focused Software Requirements…