<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: Paul Ghiran</title>
    <description>The latest articles on Forem by Paul Ghiran (@paulazasoftware).</description>
    <link>https://forem.com/paulazasoftware</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F2852536%2F700d67e8-27db-4d9c-a99d-b647942f84b9.jpg</url>
      <title>Forem: Paul Ghiran</title>
      <link>https://forem.com/paulazasoftware</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/paulazasoftware"/>
    <language>en</language>
    <item>
      <title>Build your architecture based on purpose, not schemas</title>
      <dc:creator>Paul Ghiran</dc:creator>
      <pubDate>Sat, 04 Apr 2026 21:20:59 +0000</pubDate>
      <link>https://forem.com/paulazasoftware/build-your-architecture-based-on-purpose-not-schemas-4h36</link>
      <guid>https://forem.com/paulazasoftware/build-your-architecture-based-on-purpose-not-schemas-4h36</guid>
      <description>&lt;p&gt;Here's the honest version of how most SaaS projects start: you sit down, you define your entities — &lt;code&gt;users&lt;/code&gt;, &lt;code&gt;products&lt;/code&gt;, &lt;code&gt;orders&lt;/code&gt; — you draw a schema, maybe sketch out a few services, and it all looks clean and sensible. Then you ship a few features and reality slowly dismantles the whole thing.&lt;/p&gt;


&lt;p&gt;I went through this building a product in the food space. What eventually made the system make sense wasn't a smarter architecture pattern or a better ORM. It was a different starting question.&lt;/p&gt;


&lt;h2&gt;The question I started with this time&lt;/h2&gt;


&lt;p&gt;Like any 15+ years of experience developer, I was tempted to ask myself the question "what relational schema do I need" before starting it out. But this time it was very different, I had a real understanding of the problem before I even started. I like being a host, and I like preparing food and cocktails for my guests. As such, I had a perpetual problem that always fed into itself: &lt;/p&gt;

&lt;p&gt;I would always ask myself what I want to prepare, then what the recipe is, for buying the ingredients, then what the recipe is again for preparing the thing, and then a few weeks later it would all start again, with the added complexity of "what if I have too much of X already" or "do I still have enough X left after my last supply run?"&lt;/p&gt; 

&lt;p&gt; In essence, the entities/purposes were simple: &lt;code&gt;recipes&lt;/code&gt;, &lt;code&gt;ingredients&lt;/code&gt;, &lt;code&gt;users&lt;/code&gt;. Those are real things, they obviously need to exist somewhere, so it feels like a reasonable place to start.&lt;/p&gt;


&lt;h2&gt;Start with purpose, not with tables&lt;/h2&gt;


&lt;p&gt;The very first working version of the product had exactly these core concepts: recipes and shopping lists. Not because they were some perfectly-modeled abstraction, but just because they matched what I was actually needing in that situation. There was no inventory system yet, no complex ingredient graph. Just: "I want to cook this. What do I need to buy?"&lt;/p&gt;


&lt;p&gt;That was enough to deliver a properly working product with actually logical flows that didn't need a specialized user research study. But something kept bugging me as I was developing it: Seeing how I was thinking of the purpose and not the entity, my focus was not "how do I make this or that data connection" but "how do I make it work in real life" - which naturally had me thinking about the whole inventory module long before I even wrote my first line of code about it.&lt;/p&gt;


&lt;h2&gt;The loop that defined everything&lt;/h2&gt;


&lt;p&gt;Once inventory was in, something clicked. The product wasn't a collection of features anymore — it was a cycle:&lt;/p&gt;


&lt;br&gt;
    &lt;span&gt;→&lt;/span&gt;&lt;span&gt;You generate a shopping list from your event&lt;/span&gt;&lt;br&gt;
    &lt;span&gt;→&lt;/span&gt;&lt;span&gt;You go buy the stuff&lt;/span&gt;&lt;br&gt;
    &lt;span&gt;→&lt;/span&gt;&lt;span&gt;Purchased items land in inventory(pantry)&lt;/span&gt;&lt;br&gt;
    &lt;span&gt;→&lt;/span&gt;&lt;span&gt;You cook, consuming SOME of the ingredients&lt;/span&gt;&lt;br&gt;
    &lt;span&gt;→&lt;/span&gt;&lt;span&gt;Stock runs low for some, you got too much of others&lt;/span&gt;&lt;br&gt;
    &lt;span&gt;→&lt;/span&gt;&lt;span&gt;New shopping list needs to be generated&lt;/span&gt;&lt;br&gt;
    &lt;span&gt;↻&lt;/span&gt;&lt;span&gt;Repeat&lt;/span&gt;&lt;br&gt;
  


&lt;p&gt;That loop ended up driving more architectural decisions than any schema diagram I have ever drawn. It told me where the dependencies were, what needed to talk to what, and — crucially — what &lt;em&gt;didn't&lt;/em&gt; need to be connected, or even stored in the DB.&lt;/p&gt;


&lt;h2&gt;A concrete example: generating shopping lists from recipes&lt;/h2&gt;

&lt;p&gt;If you want to &lt;a href="https://kibaco.app/blog/shopping-list-from-recipes" rel="noopener noreferrer"&gt;generate shopping lists from recipes&lt;/a&gt; you'll need the following simplified constraints:&lt;/p&gt; 


&lt;ul&gt;

    &lt;li&gt;Combine ingredients across multiple recipes&lt;/li&gt;

    &lt;li&gt;Scale quantities by serving size&lt;/li&gt;

    &lt;li&gt;Normalize units so that 200g and 0.2kg don't become two separate line items&lt;/li&gt;

    &lt;li&gt;Merge duplicates intelligently&lt;/li&gt;

    &lt;li&gt;Subtract what's already in inventory to avoid overbuying&lt;/li&gt;

  &lt;/ul&gt;


&lt;p&gt;The key insight there is that this feature doesn't cleanly "belong" to the recipes domain or the ingredients domain — it belongs to your continued purpose of knowing what to buy, then what to use, then why to buy to use again. That mindset matters when you're deciding where logic should live.&lt;/p&gt;


&lt;h2&gt;Why entity-based design creates friction&lt;/h2&gt;


&lt;p&gt;When you organize everything around entities, you end up with services like &lt;code&gt;RecipeService&lt;/code&gt;, &lt;code&gt;IngredientService&lt;/code&gt;, &lt;code&gt;InventoryService&lt;/code&gt;. And then any feature that touches real user behavior — which tends to cut across multiple entities — starts pulling in three services at once. The logic for "generate shopping list" starts leaking across all of them with no clear home.&lt;/p&gt;


&lt;p&gt;You get duplication, you get tight coupling, and eventually you get the thing where nobody's quite sure where a given piece of logic is supposed to live. The system becomes technically correct and practically painful.&lt;/p&gt;


&lt;blockquote&gt;Organizing by purpose meant asking "what is this feature &lt;em&gt;for&lt;/em&gt;?" instead of "what data does it touch?" Those are different questions and they lead to different systems.&lt;/blockquote&gt;


&lt;p&gt;Thinking in terms of planning, purchasing, and inventory management as domains — rather than recipes and ingredients as entities — gave each area clear ownership and made the architecture feel like it was developing itself - rather than an outside, arbitrary approach.&lt;/p&gt;


&lt;h2&gt;Architecture as a side effect&lt;/h2&gt;


&lt;p&gt;The mental shift that made the biggest difference: good architecture isn't something you design upfront, it's something that reveals itself when you just logically solve the problem. &lt;/p&gt;


&lt;p&gt;If I would have built out the inventory system on day one, it would've been wrong — modeled for imagined use cases rather than real ones. If I'd spent the first sprint over-engineering the ingredient model, I'd have created complexity I didn't need and painted myself into corners I couldn't foresee. Instead, this new frame of mind actually led me well into building my next &lt;a href="https://kibaco.app/modules/landing" rel="noopener noreferrer"&gt;restaurant and coffee shop management features&lt;/a&gt;&lt;/p&gt;


&lt;p&gt;Instead: start small, follow the user's actual workflow, and let the missing pieces show themselves when they're genuinely missing.&lt;/p&gt;

</description>
      <category>architecture</category>
      <category>database</category>
      <category>saas</category>
      <category>systemdesign</category>
    </item>
    <item>
      <title>Best practices for customer feedback surveys</title>
      <dc:creator>Paul Ghiran</dc:creator>
      <pubDate>Wed, 05 Mar 2025 22:15:19 +0000</pubDate>
      <link>https://forem.com/paulazasoftware/best-practices-for-customer-feedback-surveys-2p1f</link>
      <guid>https://forem.com/paulazasoftware/best-practices-for-customer-feedback-surveys-2p1f</guid>
      <description>&lt;p&gt;Customer feedback is one of the most important things you can get that has no intrinsic value in and of its own, but can be turned into a gold mine for your product. It helps you find pain points for your customers and their experiences as well as potential opportunities- think features that might make more of their peers purchase your product or tweaks that may make your service less reliant on customer support. &lt;/p&gt;

&lt;p&gt;Today we’re discussing how you can actually improve the response rates on your surveys, which is even more important for startups, where validation and revalidation is an absolute requirement for success.&lt;/p&gt;

&lt;p&gt;As the image suggests,  &lt;strong&gt;it’s mostly about time.&lt;/strong&gt;&lt;/p&gt;

&lt;h2&gt;
  
  
  Creating the Perfect Feedback Form
&lt;/h2&gt;

&lt;h3&gt;
  
  
  1.  &lt;strong&gt;Keep It Short and Focused&lt;/strong&gt;
&lt;/h3&gt;

&lt;p&gt;Research consistently shows that being concise is essential. Customers are more likely to complete a form that requires minimal time investment.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;  &lt;strong&gt;Limit the Number of Questions:&lt;/strong&gt;  Studies suggest that  forms with  &lt;strong&gt;5–7 questions&lt;/strong&gt;  tend to see a 30–50% higher completion rate  compared to longer surveys. When asking for feedback, every question should serve a clear purpose without becoming a chore.&lt;/li&gt;
&lt;li&gt;  &lt;strong&gt;Time to Complete:&lt;/strong&gt;  Try to aim for a total completion time of less than two minutes. If a form takes too long, users may abandon it before finishing, and a submitted form with 5 question responses will always be better than 20 responses to questions that you never get to read. Research shows  2 minutes is the threshold where abandonment rates skyrocket.&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;
  
  
  2.  &lt;strong&gt;Use Engaging Question Types&lt;/strong&gt;
&lt;/h3&gt;

&lt;p&gt;The way you ask questions can significantly impact response quality and engagement levels:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;  &lt;strong&gt;Multiple-Choice and Rating Scales:&lt;/strong&gt;  Questions like “How likely are you to recommend our product?” exposed as a  rating type question or multiple type choice questions  are easy for respondents to answer quickly. These types of questions have been shown to  yield up to  &lt;strong&gt;20–30% higher engagement&lt;/strong&gt;  compared to open-ended questions.&lt;/li&gt;
&lt;li&gt;  &lt;strong&gt;Open-Ended Questions:&lt;/strong&gt;  While these can provide detailed insights, they should be used sparingly. A single open-ended question at the end of the form asking for any additional comments is often sufficient.&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;
  
  
  3.  &lt;strong&gt;Optimize the Question Order and Design&lt;/strong&gt;
&lt;/h3&gt;

&lt;p&gt;A well-thought-out sequence can improve the overall user experience:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mobile-First Design:&lt;/strong&gt;  With  over 60% of internet traffic being done on mobile  devices, making sure your design is responsive is essential. Clear fonts, ample spacing, and intuitive touch targets can make a big difference.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Start Simple:&lt;/strong&gt;  Begin with straightforward questions (like ratings or multiple-choice) to warm up respondents.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Logical Flow:&lt;/strong&gt;  Group similar topics together. For example, if you’re asking about product features, keep all related questions in one section.&lt;/p&gt;

&lt;h2&gt;
  
  
  Our questions picks for high response rates
&lt;/h2&gt;

&lt;ol&gt;
&lt;li&gt; What do you like most about our product/service?&lt;/li&gt;
&lt;li&gt; What do you like least about our product/service?&lt;/li&gt;
&lt;li&gt; Was your issue resolved?&lt;/li&gt;
&lt;li&gt; How likely are you to recommend us (1-5)?&lt;/li&gt;
&lt;li&gt; How can we improve our service?&lt;/li&gt;
&lt;li&gt; Any additional comments?&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;To make sure you can get started in a jiffy, we’ve added these questions to our  &lt;strong&gt;customer feedback&lt;/strong&gt; template, which you can use to &lt;a href="https://centralfeedback.com" rel="noopener noreferrer"&gt;create your survey in seconds&lt;/a&gt; for free.&lt;/p&gt;

</description>
      <category>community</category>
      <category>operations</category>
      <category>product</category>
      <category>startup</category>
    </item>
    <item>
      <title>How to become a better Technical Trainer</title>
      <dc:creator>Paul Ghiran</dc:creator>
      <pubDate>Wed, 26 Feb 2025 18:15:44 +0000</pubDate>
      <link>https://forem.com/paulazasoftware/how-to-become-a-better-technical-trainer-1n61</link>
      <guid>https://forem.com/paulazasoftware/how-to-become-a-better-technical-trainer-1n61</guid>
      <description>&lt;p&gt;I’ve been a trainer since 2016. Throughout the years I’ve held hundreds of hours of trainings- mostly around web development, and there’s one consistent way I always managed to get better.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fil15day2m8feluwr2jrg.jpg" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fil15day2m8feluwr2jrg.jpg" alt="Image description" width="800" height="305"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I’m going to share with you a few habits that have helped me a lot along the way, so that you can become a better trainer just by leveraging your own strengths.&lt;/p&gt;

&lt;p&gt;Spoiler: It all begins with asking for, or getting feedback, but there are many ways to do it and we’ll be seeing a few of those right here.&lt;/p&gt;

&lt;h2&gt;
  
  
  How asking for feedback changed the way I work
&lt;/h2&gt;

&lt;p&gt;As a trainer, I’ve often found myself balancing between focusing on my participants or their engagement level and my actual curriculum. One of the things I’ve come to realize is there isn’t a perfect approach to all types of sessions you’re holding, some might need a faster pace that engages with the audience more because it’s a broader subject or a less technical audience, while others may require a slower pace, going more in-depth in the details of the topic you’re presenting.&lt;/p&gt;

&lt;p&gt;As you come before similar audiences or present similar concepts over time, you start to get a better sense of how your speech actually lands, how much impact it has on your participants, and you start getting the vague feeling you need to improve something about it all because it just doesn’t feel right.&lt;/p&gt;

&lt;h2&gt;
  
  
  Identifying the problem 🎯
&lt;/h2&gt;

&lt;p&gt;We often find ourselves feeling like there’s a problem, be it because our participants aren’t paying the attention we’d like them to, or because we get a lot of questions about something we’ve already covered but it just hasn’t hit its mark.&lt;/p&gt;

&lt;p&gt;Here’s a few ways you can find what’s holding you back as a trainer:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;Make short pauses, use them to observe the participants and whether they’re paying attention to you or they’ve gotten distracted by their phones, for example.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Ask open questions – This will help you get an understanding of what the audience thinks, and observe not just how well the message got across, but actually how many of them are willing to engage with you.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Ask for feedback at the end of your sessions – While you can get a pulse during your performance with the aforementioned methods, you will not be able to go into details about how or why, so the best time to ask for details it is right after you are done.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h2&gt;
  
  
  Asking for feedback
&lt;/h2&gt;

&lt;p&gt;This is a simple comparison between the ways you can get feedback from multiple people with pros and cons:&lt;/p&gt;

&lt;h4&gt;
  
  
  Spoken Feedback 🗣️
&lt;/h4&gt;

&lt;p&gt;(open or private discussion)&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Pros&lt;/strong&gt;:&lt;/p&gt;

&lt;p&gt;Speech is the fastest way for information to be transferred between people.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Cons&lt;/strong&gt;:&lt;/p&gt;

&lt;p&gt;Impractical for large audiences.&lt;br&gt;
Some people might be more introverted or less interested to provide you with said feedback. As such, you might get an empty answer or rejection from some people.&lt;br&gt;
What ever isn’t written down, can unfortunately be easily forgotten.&lt;/p&gt;

&lt;h4&gt;
  
  
  Written Feedback ✏️
&lt;/h4&gt;

&lt;p&gt;(like post it notes)&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Pros&lt;/strong&gt;:&lt;/p&gt;

&lt;p&gt;It can easily be anonymous, and people can be more comfortable sharing the feedback in a written manner.&lt;br&gt;
Writing with a pen can increase creativity, leading to more complete answers.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Cons&lt;/strong&gt;:&lt;br&gt;
Not everyone has great handwriting, and you might end up missing out on a few notes if you don’t notice in time.&lt;br&gt;
Losing physical notes is always a risk, and you’re often creating a mess or scrambling for pens.&lt;/p&gt;

&lt;h4&gt;
  
  
  Digital Feedback 📝
&lt;/h4&gt;

&lt;p&gt;&lt;strong&gt;Pros&lt;/strong&gt;:&lt;br&gt;
Much easier to create and distribute &lt;a href="https://centralfeedback.com" rel="noopener noreferrer"&gt;online forms&lt;/a&gt;&lt;br&gt;
You can use your forms endlessly without needing any paper or pens&lt;br&gt;
Works for any audience size, asynchronously or even after the fact by sending a link.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Cons&lt;/strong&gt;:&lt;br&gt;
Many online form builders can be expensive, charging upwards of $20-50 per month.&lt;br&gt;
Some demographics might be less inclined to use technology in general.&lt;/p&gt;

&lt;h3&gt;
  
  
  Where that lead me
&lt;/h3&gt;

&lt;p&gt;Currently, what I found works out best for me is making sure I have an online form prepared for every occasion- be it one per course session or one for a whole series of sessions. I can easily share them as a QR code so anyone with a phone can get the link and fill it out in their own pace.&lt;/p&gt;

&lt;p&gt;As I gather more feedback I always go back to revisit the feedback over time to see how I evolved and how my attempts to improve certain behaviors like filler words improve, as they get mentioned less and less throughout the feedback. For large feedback sets, I tend to use AI to extract summaries when looking at old forms, which is one of the features I find most useful in &lt;a href="https://centralfeedback.com" rel="noopener noreferrer"&gt;Central Feedback&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;In time, you will get to see trends across all your deliveries, like “you could smile more” which is a common one for many people starting out, or “your jokes really help switch up the pace from more serious concepts” which is one piece of feedback I’m constantly trying to get. General feedback is just as valuable as per-session feedback, because you’ll know where you stand in terms of your own style and how you can appeal to the generic, unknown, audience.&lt;/p&gt;

&lt;h3&gt;
  
  
  Where it should lead you
&lt;/h3&gt;

&lt;p&gt;One thing you will get to notice at some point, is that you’ll receive similar feedback on similar topics, and similar feedback from similar audiences:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Your explanation of […] was much too rushed, I couldn’t follow the next part where you built on top of it.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;You might get to something as small as a concept or definition that is overwhelming or underwhelming and ends up derailing the rest of your talk for a great chunk of your audience. It happens a lot with technical topics, and you’ll be hard pressed to identify what exactly goes wrong without asking people.&lt;/p&gt;

&lt;h3&gt;
  
  
  In conclusion
&lt;/h3&gt;

&lt;p&gt;The best advice I can give you is: Create a &lt;a href="https://centralfeedback.com" rel="noopener noreferrer"&gt;free online form&lt;/a&gt; and start gathering feedback now, and in time your way to becoming better will make itself obvious to you.&lt;/p&gt;

&lt;p&gt;This article was initially posted on the &lt;a href="https://centralfeedback.com/blog/central-feedback-for-trainers" rel="noopener noreferrer"&gt;Central Feedback Blog&lt;/a&gt;.&lt;/p&gt;

</description>
      <category>speaking</category>
      <category>career</category>
      <category>productivity</category>
      <category>programming</category>
    </item>
  </channel>
</rss>
