It’s been a while since I shared insights into software architecture. Today, I’m kicking off a new series where I’ll explain into the technical aspects of my work.
As a CTO in a startup environment, I’m constantly seeking ways to enhance our software solutions. However, every development project, whether it’s a brand new initiative or an existing application enhancement, has a critical starting point – requirement gathering.
In established companies, software engineers typically receive well-defined requirements from project managers or leads. These requirements are meticulously reviewed across various domains, including system design, application architecture, data flow, and user experience (UX/UI). Such comprehensive requirements stem from rigorous research, analysis, and evaluation.
However, startups often lack dedicated resources for each specialized role, and a single engineer may need to wear multiple hats, ranging from system design to application deployment. This is precisely the scenario I encounter in my work as a CTO, where I also assume roles ranging from system architect to Quality Assurance (QA) Lead.
Additionally, I undertake side projects, creating basic websites for friends and family members seeking to digitize their businesses. Naturally, I handle a diverse range of applications, from complex smart contract-based fintech solutions (which have transacted over 1 Million SGD) to simple static websites hosted on platforms like GitHub or Cloudflare Pages.
Regardless of an application’s complexity, I firmly believe in gathering requirements from the ultimate beneficiaries. This process is not straightforward, as not all stakeholders possess an IT background. Here’s my approach:
- Collaborative Documentation: For every project, I create a shared document (e.g., OneDrive file, Zoho Docs, or Google Doc) and invite all stakeholders, including beneficiaries and developers (for work-related applications). Most stakeholders are often occupied with their work, making it challenging to schedule hour-long meetings consistently. To address this, I encourage stakeholders to text their requirements via WhatsApp, which I promptly document in our shared document. This method ensures that even if we can’t meet in person, everyone’s input is captured and can be referred to at any time. Unlike traditional methods like questionnaires or interviews, this approach allows stakeholders to conveniently contribute their requirements, promoting alignment throughout the process.
- Use Case Visualization: Once basic requirements are collected, I use a visualization tool like LucidChart to define use case scenarios. Presenting these visual representations allows stakeholders to rethink and refine their initial requirements. This crucial phase helps clarify expectations and rectify any missing or unnecessary elements while the requirements are still in a textual format.
- Approval and Next Steps: When stakeholders approve the requirements, I explain the necessary information I’ll need from them, such as product/service details for a static website or domain name access for hosting setup. I also provide a timeline for when they can expect to see the application. Regardless of the project, I remain open to modifying or enhancing the solution based on their evolving needs.
With requirements gathered and approved, it’s time to dive into the actual development process. This involves making critical decisions about the technical implementation, such as choosing the appropriate hosting platform (e.g., cloud providers like AWS, Azure, or self-hosted servers) and selecting the right technology stack (programming languages, frameworks, databases, etc.) based on the project’s needs.
Each project is unique, presenting its own set of technical challenges and considerations. In subsequent blog posts, I’ll share insights into navigating these technical aspects, from architecting scalable solutions to deploying and maintaining robust applications. Until then, happy reading, and stay tuned for more insights!