fix: typos

public/blogs/code-silos.mdx

@@ -13,7 +13,7 @@ tags:
   - 'skill-issues'
 ---
 <C>
-In a traditional sense, the retention of programmers for extended periods has been equated with success. But one problem is this perspective overlooks the potential negative consequences of prolonged exposure to the same codebase. Over time, programmers may develop a sense of entrenched ownership over specific sections of code.
+In a traditional sense, the retention of developers for extended periods has been equated with success. But one problem is this perspective overlooks the potential negative consequences of prolonged exposure to the same codebase. Over time, programmers may develop a sense of entrenched ownership over specific sections of code.
 </C>
 <C>
 It often results in a culture where one or a few individuals become the sole experts on certain parts of the codebase. This can lead to a complete reliance on these individuals for troubleshooting and decision-making, which hinders collaborative work and impedes overall team agility, and forces everyone to depend on these people for project success, even if they are underperforming. And if they suddenly quit, the project is destined to fail.

public/services/full-software-solution.mdx

@@ -34,19 +34,19 @@ Our focus then shifts to understanding the essential aspects of the project and
 <S3/>
 We go deep into understanding your needs, target market, existing solutions, and how we can enhance them. This entails establishing a clear scope and purpose for the project. Critical questions guide this phase: Who are the users and what roles do they play? What exact needs and pain points does the product aim to address? How will the proposed solution surpass existing offerings? Who's effected by it? What are the software's key functionalities, key features, and capabilities? 
 </C>
-<H2>Software Requirements Specification</H2>
+<H2>Laying The Groundwork</H2>
 <C>
- We transition into setting the <L href="https://standards.ieee.org/ieee/830/1222/">SRS</L>, which involves scrutinizing requirements, eliminating redundancies, setting up a <L href="/services/glossary">glossary</L>, identifying key priorities, developing schemas, <L href="/services/glossary#user-stories">User Stories</L>, <L href="https://www.bpmn.org/">BPMNs</L>, <L href="https://github.com/joelparkerhenderson/architecture-decision-record">ADRs</L> ... 
+ We transition into setting the <L href="https://standards.ieee.org/ieee/830/1222/">SRS</L>,  scrutinizing requirements, eliminating redundancies, setting up a <L href="/services/glossary">glossary</L>, identifying key priorities, developing schemas, <L href="/services/glossary#user-stories">User Stories</L>, <L href="https://www.bpmn.org/">BPMNs</L>, <L href="https://github.com/joelparkerhenderson/architecture-decision-record">ADRs</L> ... 
 <S2/> 
 Refinement and Iteration come in handy. If clarity is lacking, we ask further questions and refine our analysis until no more refinement is needed, and no outstanding questions remain. with this, requirements are sealed and the project is ready for development. The process takes anywhere from 5 days to 2 weeks to finish.
 </C>
 <H2>Proof Of Concept</H2>
 <C>
-Next, is the **PoC**. This requires building the product according to the specification in a very limited time frame. The result will have multiple bugs and open ends, but it will implement the main user story. This phase typically lasts 2-5 days.
+Next, is the **PoC**. This requires building the product according to the specification in a very limited time frame. The result will have multiple bugs and open ends, but it will implement the main feature(s). This phase typically lasts 2-5 days.
 </C>
 <H2>Development & Refinement</H2>
 <C>
-This phase takes most of the time and budget, it will involve many participants to work simultaneously with me. Since all inconsistencies are treated as <L href="/services/glossary#ticket">issues</L> that are yet to be resolved, this phase is mostly about finding, reporting, and fixing as many <L href="/services/glossary#ticket">bugs</L> as possible to stabilize the product and get it ready for market launch. We incrementally release a working version of the software multiple times a day, week or month, which leads us to the next phase:
+This phase takes most of the time and budget, it will involve many participants to work simultaneously with me. Since all inconsistencies are treated as <L href="/services/glossary#ticket">issues</L> that are yet to be resolved, this phase is mostly about finding, reporting, and fixing as many <L href="/services/glossary#ticket">bugs</L> as possible to stabilize the product and get it ready for market launch. We incrementally release a working version of the software multiple times a day/week, which leads us to the next phase:
 </C>
 <H2>Launch & Feedback</H2>
 <C>

src/app/(pages)/services/_services.tsx

@@ -50,7 +50,9 @@ export default function Services({
                   transition={transition}
                   className="dimmed-1  md:text-xl/relaxed lg:text-base/relaxed xl:text-xl/relaxed"
                 >
-                  <i>&quot;I&apos;m winston wolf, I solve problems&quot;</i>
+                  <i className="">
+                    &quot;I&apos;m winston wolf, I solve problems&quot;
+                  </i>
                   <br />
                   If you use my
                   <Link href="/about#stack">