My CTO has a strong philosophy: “Doesn’t matter how smart your backend is — if the UI doesn’t make people feel like they’re using something powerful, they won’t.” And honestly… he’s right. So before we push this out publicly, I wanted to get some honest feedback on the UI from founders, designers, newsletter operators, and devs who care about clean product experiences. Here are a few screens from the current build: (You can find 3 screenshots attached) 🔍 Quick context (non-technical explanation): MK1 basically takes multiple newsletter issues → breaks them down into structured insights → and shows patterns across the entire niche. The UI’s job is to make all of that complexity feel simple. Some things the UI needs to communicate clearly: - Tone + intent of each issue - Niche-wide benchmarks - Issue-level metrics - Structure breakdowns (titles, sections, visuals, CTAs, etc.) - Engagement patterns (vs word count, vs structure) - Individual issue summaries - Consistency markers across creators The backend is… not small.It’s a full distributed pipeline (scraping → TOON compression → issue-level LLM runs → aggregation), but none of that matters if the UI doesn’t let people understand the story instantly. 🧠 What I’m specifically looking for feedback on: 1. Does it feel intuitive at first glance? 2. Are the insights easy to digest, or does it feel “dashboard complicated”? 3. Which parts feel unnecessary or too heavy? 4. Do the cards/graphs help or distract? 5. Does this UI make you want to explore deeper? 6. If you ran a newsletter or content team, would this type of layout actually help you? We’re still tweaking visual hierarchy, spacing, and how much data to surface at once — so I’m open to brutal honesty. 💬 The bigger question (UI philosophy): Do you think products like this succeed because of UI,or despite it? Some founders believe “if the model is good, UI is secondary.”My CTO believes the UI is the major part of a product, and everything else is invisible unless the UI communicates it well.

Hi All - Getting a bit overwhelmed with the total amount of clients I am getting now. Looking for someone to join the team who has a solid background with n8n and make.com as well (some clients are already using that). If you are someone who is looking for a gig, let me know below and DM me as well with any relevant experience you may have. Happy Building :)

We’re building an agent (MK1) that does large-scale competitor analysis across dozens of newsletters automatically! Scraping → Structuring → Compressing → Multi-LLM analysis → aggregation → dashboards. If it were as simple as “drag a few n8n nodes,” trust me, we’d be doing that. Allow me to elaborate: 1. The data sources we pull from are NOT friendly to scrapers. - Requests get blocked instantly - HTML structure changes unpredictably - Anti-bot systems shut down your pipeline mid-run - Content loads dynamically - Layouts differ per issue - Rate limits kick in - Rendering methods break your parser When you have to keep the entire structure consistent for downstream LLM analysis, a single DOM change breaks the whole chain. No-code tools don't handle that kind of fragility well. 2. The content isn’t simple text, it requires meaningful structure. When you’re analyzing 30–100 newsletters at a time, you need: - Section extraction - Visual mapping - CTA identification - Ad block recognition - Tone markers - Intent patterns - Word & emoji stats - Structural compression (to cut token costs by ~70%) 3. Real orchestration > visual workflows People underestimate what happens when you’re: - Running 40+ analysis jobs in parallel - Retrying failed tasks - Re-queuing partial data - Handling timeouts - Managing token budgets - Caching compressed representations - Tracing every run end-to-end - Ensuring idempotency 4. Maintaining the scraper is half the battle When the website changes structure (which happens often), your scraper must: - adapt automatically or - be fixable with minimal downtime You cannot do that reliably in a visual builder. These aren’t static URLs. Each issue is rendered differently and sometimes changes backend structure.Our scraping approach has to evolve constantly. Even a small structure shift breaks an entire n8n chain.

I am looking for a select few of experienced developers that can take on jobs for my AI consulting agency. We have reached a volume of new jobs that I can no longer handle on my own. If you are an n8n specialist, no-code tool specialist, voice ai specialist, or anything of the sorts I would love to chat!

We’re working with a newsletter agency that wants their competitor research fully automated. Right now, their team has to manually: - Subscribe to dozens of newsletters - Read every new issue - Track patterns (hooks, formats, CTAs, ads, tone, sections, writing style) - Reverse-engineer audience + growth strategies We’re trying to take that entire workflow and turn it into a single “run analysis” action. High-level goal: - Efficiently scrape competitor newsletters - Structure them into a compressed format - Run parallel issue-level analyses - Aggregate insights across competitors - Produce analytics-style outputs - Track every request through the whole distributed system How the system works (current design): Step 1 – You trigger an analysis You give the niche. The system finds relevant competitors. Step 2 – Scraper fetches issues Our engine pulls their latest issues, cleans them, and prepares them for analysis. Step 3 – Convert each issue into a “structured compact format” Instead of sending messy HTML to the LLM, we: - extract sections, visuals, links, CTAs, and copy - convert them into a structured, compressed representationThis cuts token usage down heavily. Step 4 – LLM analyzes each issue We ask the model to: - detect tone - extract key insights - identify intent - spot promotional content - summarize sections Step 5 – System aggregates insights Across all issues from all competitors. Step 6 – Results surface in a dashboard / API layer So the team can actually use the insights, not just stare at prompts. Now I’m very curious: what tech would you use to build this, and how would you orchestrate it? P.S. We avoid n8n-style builders here — they’re fun until you need multi-step agents, custom token compression, caching, and real error handling across a distributed workload. At that point, “boring” Python + queues starts looking very attractive again.