Iteration speed matters: Get your customers using your product
Getting product in front of your customers quickly is imperative - especially for unverified ideas. Sometimes you can do this with design prototypes and wireframes, but the real test and the real feedback, only comes when real people are using real product. There is no substitute for the real deal.
Why we use ReactJS to deliver products quickly
ReactJS is the leading frontend library, with the biggest ecosystem from which we can leverage existing libraries, frameworks and general written materials. When you aim to deliver fast, spending a day wrapping some some library to be usable in Vue, Svelte or Solid isn't an option.
Knowing your tools is the number one thing to boost productivity. We do all our frontends, web or mobile, with ReactJS. It's a second language, and once you reach this level of proficiency and depth, one gets really good at cranking out features fast.
The importance of having product-oriented developers who understand customers' needs
Developers need to understand the business problems that are being solved. That means getting into the minds of the customers, seeing the pains they experience, having empathy for them, and understanding how this product will alleviate their suffering.
If one can instil this way of thinking in the person that is crafting your product, the chances of success will increase manyfold.
Besides being really good React developers, we're product-oriented developers that care about the problem you are solving. Most other agencies will separate the "business thinking" or project management to separate persons, that will instruct the "techies" on what to do, but it's like attaching chains between the legs of a group of people and telling them to run as fast as they can - it's clumsy at best.
Developers who understand requirements and your business, and know technical trade-offs of implementation details versus the value for your business, have the skills to make spur of the moment micro-decision throughout the day to ensure projects stay on track, on budget, and on time.
Fewer people means
less miscommunication
Your team should be as small as possible. This is why full stack developers really matter. Having less chefs in the kitchen will let you decrease the amount of people in your project.
70% of IT projects fail [Source: the internet]. Many times this isn't a technology problem, but mainly a communication problem. Too many stakeholders, developers, designers, usability experts, project managers, product managers. It becomes a cacophony inviting failure due to miscommunication. Instead of getting rid of the unnecessary people, the instinct becomes more meetings and alignment sessions. This slows everything down to a crawl and budgets explode, and makes it impossible to pivot quickly or try new ideas ad-hoc.
A small tight-knit team of 1-3 skilled developers granted the responsibility and freedom for decision making is the best way of increasing project success.
Have I mentioned Communication?
It's sort of important
We know smaller teams can communicate more efficiently, but the team needs to interface with you as well if you're not part of the team. Previously, this would've been facilitated by co-locating everyone in a single room, where they would do their work all day and all week. Communication was pretty much guaranteed due to proximity. In the remote world, the ways of communicating have changed drastically.
Nothing is as efficient as face-to-face communication, which is why we still have regular video conferences. Brief daily stand-ups via video conferences every morning sets the rhythm for the day and keeps everyone aligned. For short ad-hoc messages, Slack rules, but what really makes the difference is short async videos, e.g. using Slack or Loom. It decreases miscommunication and back-and-forth dialogues due to misunderstandings many-fold. Written messages do not pack the same information density as video - and since its effortless to create an async video message with screen share, it's far quicker to convey ideas via recorded videos than carefully written emails.
Since all team members work in the same timezone, it is also easy for us to jump into a huddle (voice-only conference with screen sharing) to quickly solve problems that spring up.
We still use traditional PM tools with Kanban boards in Asana, and those are great for overviews and weekly syncs. The task descriptions are great for initial specifications, but for fast moving teams, the detailed information in such systems don't age well, and we need our information streams in a single place (Slack) around which most communication is centralized.
Skilled developers can move fast without breaking things
Be pragmatic about testing. Unit testing can make you faster, but it can also make your application code more rigid, and when business requirements change fast, you need to change your code fast, and the value of those tests will evaporate fast. Not writing tests doesn't mean one needs to write unmaintainable spaghetti code through some law of nature.
Your developers need to have the common sense to know when testing adds value. It's completely ok to push out prototypes without any tests. If the market validates those prototypes we can add high level end-to-end tests, such as Cypress to prevent regressions.
Skilled developers know how to deliver code fast, making compromises on certain aspects without letting project velocity suffer in the future. This is the skill of engineering. This is why you should work with skilled developers.
Leverage existing frameworks, platforms and services over custom solutions
I mentioned knowing your tools like ReactJS is key, but don't forego picking high level tools you repeatedly use in many projects.
That means picking high level frameworks, like NextJS or BlitzJS as your full-stack framework, Shopify as your e-commerce backend, Storyblok as your content management system, and e.g. Vercel as your CI/CD and deployment platform, and sticking to those from project to project. Not spending an hour reading up on documentation, because you already know a framework or API like the back of your hand, creates predictability. For this reason we have our own tech-radar of company approved services & tools, so we can foster familiarity of approaches across projects.
Custom solutions are almost always the wrong choice. A company backed service, platform or framework will continuously receive updates and new features without any investment from you. Even if it costs something, if you can avoid developing something custom for $10-$100/month, it's likely worth just buying that service for now.
I've seen too many unnecessary DevOps projects, prematurely setting up custom CI/CD-pipelines, or even Kubernetes clusters. These are largely solved problems and have been productized by numerous providers online. You can create custom infrastructure and pipelines once your product has product-market fit, and you have a reason to start optimizing hosting costs.
Conclusion
This is mostly about common sense, i.e. accepting the world as it is. You can't force order on something that is inherently chaotic. You need to embrace it, and create systems and people that are resilient to the unexpected.
That means optimizing for customer feedback, small teams, fast iteration, leverage existing libraries, platforms and services, communicating effectively, and moving fast without creating a mess. Simple common sense.
