Influencer checklist

We'll close out the chapter with a few checklists. These are simple questions for which there's no one correct answer. Some answers will remain the same throughout the lifetime of our software. For example, our business model will, hopefully, 'not change often. Others depend on the current state of things, and that's what these lists are for. We can come back to them again and again, anytime something changes. These could be requirements, users, new deployments, or changes to the development environment. These questions are nothing more than subtle reminders of the factors that influence scalable JavaScript applications. If reading them results in more questions than answers, then they've served their purpose.

User checklist

The user is why we build software in the first place. This checklist covers the most fundamental aspects of why we need to scale our application. These questions will be relevant throughout the lifetime of the software. And not just when something with the user management perspective is in question. Changes to feature development should trigger a look at this list.

What's the business model of our software?

• Is it license-based?
• Is it subscription-based?
• Is it consumption-based?
• Is it advertisement-based?
• Is it open source?

Does our application have different user roles?

• Are features hidden from one role while visible to others?
• Does every feature in our application have to be role-aware?
• How are roles defined and administered?
• How does our business model influence the use of roles in our application?

Do our users communicate with each other using our software?

• Do users collaborate with each other to use our application effectively?
• Does user communication happen as a side-effect of our data model?
• How do the user roles in our application influence user communication?

How do we support our application?

• Is support built into the application, or handled externally?
• Can users support each other using a central knowledge repository?
• How do our business model and application user roles influence the type of support we need to provide?

How do we collect feedback from users?

• Is feedback collection built into the application, or handled externally?
• How do we incentivize users to provide feedback?
• How does the type of support we provide influence the type of feedback we want to collect?

How do we notify users with relevant information?

• Does our application have a generic, context-independent notification mechanism?
• How do we ensure that only relevant notifications take place at any given time?
• Can users audit their notifications?

What type of user metrics should we collect?

• Do we use metrics to improve future versions of the product?
• Can our features use metrics at runtime to improve the user experience?
• How does the business model influence our need to collect metrics?

Feature checklist

Following the scaling influencers that originate from users of our software, are the features of our software. This list covers some of the questions we should be asking ourselves about any new feature, or implementing changes in an existing feature. They'll help us address the common issues related to scalability on a per-feature basis.

What's the core value proposition of our software?

• Does the feature we're implementing or enhancing contribute to the overall value proposition of our product?
• Is our current value proposition too broadly focused?
• How do the number of users and their roles influence our ability to focus on features relevant to our application's value?

How do we determine the feasibility of a feature?

• Are we trying to implement killer features instead of letting them come about naturally?
• Do we take the time to determine whether a proposed feature is feasible to implement, rather than implementing it poorly?
• How does the value proposition of our software, and the feature requests from our users, influence the feasibility of the features we ultimately implement?

Can we make informed decisions about our features?

• Do we have any user metric data on which we can base our decisions?
• Is there any historical data on similar features we've implemented in the past?
• How does our business model influence the data we can collect and use for decisions about the features of our application?

Who's our competition?

• Are we offering something similar to a competing product, done better?
• Are we in a niché market?
• What can we learn from competing products?
• How does our business model influence the amount of competition we face and the types of features we need to implement?

How do we make what we have better?

• Given the rate at which we're adding features, do we have enough time to maintain our existing features?
• Is it safe, architecturally, to modify a feature without breaking other features?
• How do our users influence the enhancements we make to existing features?
• How does our business model influence our ability to deploy product enhancements?

How do we integrate user management into our features?

• Are access control mechanisms generalized to the point that they're not a day-to-day concern for feature development?
• Can we organize our features into groups?
• Can users turn features on or off?
• How does the type of application we're building, in conjunction with our users and their roles, influence the complexity of our features?

Are our features tightly coupled to backend services?

• Are the existing services generic enough to handle the new feature we're implementing?
• Are we able to mock back-end services, running entirely in the browser?
• How do our features influence the design and capabilities of back-end services?

How does the frontend stay synchronized with backend data?

• Can we utilize web socket connectivity for push notifications?
• Does high user activity cause more messages to be delivered to other users?
• How does consuming real-time data influence the complexity of our features?

Developer checklist

The final checklist we'll want to review throughout the course of our software is concerned with development resources. This checklist won't be used as frequently as the users or the features lists. Nonetheless, it's important to make sure we're addressing the concerns that arise in terms of development resources.

How do we find the right development resources?

• Can we get by with the development resources we currently have?
• Do we need to revisit the features under development to accommodate the resources we have?
• Do we have the right development resources for the product we're building?

How do we allocate development responsibilities?

• How much overlap should there be between areas of responsibility?
• Do our current areas of responsibility reflect what we're building?
• How do the various skill-sets of our team members influence the responsibilities?

Can we avoid hiring too many resources?

• Are we hiring people too far in advance of actually needing them?
• Are we experiencing communication overhead due to too many resources?
• How does the number of features under development in parallel, influence the perception that more developers means more will be accomplished?