Inside Fora Soft’s Analytics Team: 20 Years of Turning Chaos Into Buildable Products

Why Fora Soft wrote this piece

This article is a behind-the-scenes look at how our analytics team works, because the boring truth of software projects is that the team doing discovery and analysis matters at least as much as the team writing code. Fora Soft has shipped 625+ projects over 20 years in video, AI, telemedicine, e-learning, and surveillance (see our flagship case studies like BrainCert and V.A.L.T.). Almost none of those projects would have landed on-scope without the analysts catching things before implementation.

If you’re evaluating development partners, the question “who does the analysis?” is more predictive of project success than “who does the code?”. This piece explains how we staff, what the team does, which tools we use, where AI fits, and — concretely — what you can expect when you start a project with us.

What our analysts actually do on your project

“Business analyst” is a broad title. In our practice it covers a specific set of deliverables that show up in every project, regardless of industry.

1. Problem reframing. Clients often walk in describing a solution (“I need an app like X”). The analyst’s first job is to dig for the actual problem — the user behavior, business outcome, or compliance pain that “app like X” is a proxy for. We reframe before we estimate.

2. Requirement capture and prioritization. User stories, acceptance criteria, edge cases, non-functional requirements (latency, uptime, compliance). We prioritize with MoSCoW or RICE so the roadmap is grounded in value, not wishlist.

3. Visualization. Wireframes first in Visily (2× faster than hand-drawing) and Axure RP for interactive prototypes; process diagrams in Whimsical/Miro; data-flow and sequence diagrams in Mermaid or Lucidchart. See our take on AI wireframe tools and wireframing in software development.

4. Technical translation. Our analysts speak both languages — APIs, architecture, latency envelopes — so that when we tell an engineer what to build, it’s unambiguous.

5. Estimation support. We contribute to the software estimation process by scoping features with engineers and flagging risk-heavy items. When a range is given, there’s a reason behind each boundary.

6. In-sprint continuity. Our analysts stay in the room during sprints — not to “do analysis” but to catch drift, answer developer questions, and push back on unscoped additions.

7. User defense. When business goals collide with usability, the analyst checks “is this convenient? does it solve the user’s problem?” That’s a role no other team member reliably takes.

Our analytics process, stage by stage

We run four analytical phases that bracket the engineering work.

Phase 1 — Discovery (1–2 weeks). Stakeholder interviews, competitor teardowns, user-journey drafts, tech-stack feasibility, assumption list. Output: a problem statement, shortlisted solution approaches, a risk register.

Phase 2 — Scoping (1–3 weeks). Low-fidelity wireframes in Visily, user-story map, priority matrix, estimation ranges with engineering. Output: a roadmap draft, MVP cutline, and a defensible estimate. Our personalized planning process goes deeper on this stage.

Phase 3 — Detailed design (2–4 weeks). High-fidelity wireframes in Axure, interaction specs, data-flow diagrams, API contract sketches. Engineers start building alongside. Output: the documentation the team actually uses to ship.

Phase 4 — In-flight support (continuous). Every sprint, the analyst clarifies edge cases, refines upcoming stories, and keeps documentation current. Post-launch, they feed user data and analytics back into the roadmap.

Figure 1. The four analytical phases that wrap every Fora Soft engagement.

The tools and stack our analysts run

We don’t force a tool; we force an output. But here’s the stack that hits the fastest time-to-clarity for most projects.

How AI changed our analytics workflow

We’re not replacing analysts with AI. We’re giving them a power tool. What changed measurably:

1. Call summarization & action extraction. A 90-minute stakeholder call used to need a 2-hour write-up. With LLMs it’s 15 minutes, and the analyst fact-checks rather than transcribes.

2. Wireframe drafting. Visily generates a first-pass layout from a prompt; the analyst then edits for fit, not for pixel-pushing. Throughput roughly doubles on the low-fi wireframe stage.

3. Requirement stress-testing. Feeding a draft user story to an LLM and asking “what’s missing?” catches 60–80% of edge cases we used to catch only in review meetings.

4. Competitive research. LLM-assisted teardowns of 5–10 competitors in a morning instead of a week.

The takeaway is that AI shifts the analyst’s time toward judgment work — where AI is weakest — and away from typing. This matches our broader agent-engineering practice, which uses the same pattern for coding.

The ten principles our analysts live by

1. Learn to hear, not just listen. Clients describe solutions; your job is to uncover the real problem.

2. Ask the right questions. Open-ended, clarifying, and willing to go four “whys” deep.

3. Structure the chaos. Turn tangled ideas into user stories, diagrams, and logic.

4. Think in scenarios. Not “what can the system do,” but “what happens when a user does X.”

5. Be technically literate. You don’t code, but you know APIs, architecture, and limitations.

6. Write clearly. Clients recognize their idea; developers know exactly what to build.

7. Embrace conflict. Uncomfortable questions early beat painful fixes late.

8. Defend the user. When business goals drown out usability, push back.

9. Visualize everything. Wireframes, maps, diagrams — complex becomes simple.

10. Manage expectations. Everyone wants everything fast; your job is to show the realistic path.

What you get in the first three weeks

Here’s a concrete deliverables map for a typical project kickoff.

Mini case: when analytics saved a six-figure quarter

We can’t tell every story, but one pattern repeats. A client came in with a clear “build me feature X for compliance reason Y” brief and a fixed deadline. Our analyst, in the first week, dug into Y and found that regulators had published a revised interpretation three months earlier — the original feature would have been non-compliant the day it launched.

Cost of that finding, pre-code: a 1-week pivot and a re-scoping meeting. Cost if we’d built the original feature and discovered the drift post-launch: rewriting the feature, re-auditing, and explaining to end customers why compliance slipped. Six figures easily, plus the soft damage to trust.

We’ve seen the same shape across our biggest projects — BrainCert’s 500M+ delivered minutes, V.A.L.T.’s 770+ organizations, Tradecaster’s complex live-trading workflows. None of them are the idea the client walked in with. The analyst’s job was to help find the better one, early.

How the analytics team is structured

Our analytics org is deliberately flat. Each project gets a lead analyst who owns the relationship and deliverables; complex engagements add a supporting analyst or a domain specialist (video, AI, compliance). Above them sits a head of analytics who coaches on craft and escalates resourcing.

No one is “just a note-taker.” Every analyst owns the output of a project and has authority to push back on both clients and engineers when something doesn’t fit.

How to get the most out of working with our analysts

1. Show your problem, not your solution. The best first calls bring a messy problem statement, not a polished feature list.

2. Put stakeholders on the call. A decision-maker and a domain expert in the room beat five rounds of back-and-forth email.

3. Share what you’ve already tried. Failed vendor engagements, internal prototypes, competitor inspiration — the analyst can reuse that context fast.

4. Be honest about constraints. Budget, timeline, compliance, legacy systems. Surprise constraints surface eventually; the earlier, the better.

5. Let us challenge you. If a question feels uncomfortable, it’s probably the right question. Our job isn’t to nod along.

Decision framework — do you need an analyst on your build?

Q1. Have you shipped this kind of product before? If no, you need an analyst.

Q2. Are there more than two stakeholders with different success criteria? If yes, you need an analyst.

Q3. Is there regulatory or compliance exposure? If yes, you need a senior analyst.

Q4. Is the estimate below $30k and the scope a single well-understood feature? You might skip — but keep an analyst on call for a half-day review.

Q5. Will this product evolve for more than six months? If yes, the analyst needs to stay on through delivery, not just kickoff.

Five pitfalls that kill the analyst’s value

1. Treating analysis as a throwaway phase. Clients who want “just get me to code” burn the analyst budget without reaping it in clarity.

2. Putting a junior BA on a complex product. Domain complexity and a junior analyst are a bad match — they will miss the constraints that matter.

3. Letting documentation live only in the analyst’s head. If it’s not in Notion or Confluence, it doesn’t exist.

4. Separating analysis from engineering. Analysts who don’t sit in sprint reviews lose context fast; they become scribes, not partners.

5. Skipping user-defense. If the analyst never says “the user won’t do that,” they’re not doing half their job.

KPIs we hold our analytics team to

Quality KPIs. Post-implementation requirement-change rate (target <10%). Defect rate on stories written by the analyst (target <5% rework).

Business KPIs. Estimate accuracy (delivered-vs-quoted within ±15%). Client NPS on analysis phase (target >50). Percentage of projects that hit MVP deadline (target >90%).

Growth KPIs. Analyst productivity uplift year-over-year (target 20%+ with AI tooling). Retention of senior analysts (target >90% annually).

When you don’t need a Fora Soft analyst

If your product is a well-understood variation of something you’ve shipped before, with a single stakeholder and no regulatory exposure, you can often run with a senior engineer driving the plan. We’d rather tell you that than charge for unneeded analysis hours.

The moment the product crosses into multi-domain, multi-stakeholder, or regulated territory, the analyst becomes the highest-leverage role in the project. That’s most of what we build.

Agent engineering + analysis = faster projects

Our analysts feed their outputs directly into our spec-driven agent-engineering pipeline. Clear stories become high-quality agent prompts; wireframes become testable acceptance criteria; diagrams become architectural scaffolding. The analyst-engineer handoff is now the highest-ROI automation we’ve ever built.

Practical effect: projects that would have been 20-week builds are 12–14 weeks; the analyst’s time gets returned as faster delivery, not as budget for more typing. That’s why our estimates beat incumbents on both price and timeline — not because we rush analysis, but because we’ve wired it into the engine.

A note on culture

Working at Fora Soft analytics is demanding. The standards are high, the review culture is direct, the senior analysts push juniors hard. That’s by design — analysis is the craft that separates projects that ship from projects that drift.

What stops it from being grinding: a team that shares ideas, supports each other, celebrates wins, and treats the craft like craftsmanship. We build with our heads, but we lead with our hearts. That’s what clients feel in the first call, and what keeps our projects coming back for second, third, and tenth engagements.

Where we’re taking the practice next

1. Deeper AI tooling. Agents that draft user stories, generate acceptance criteria, and pressure-test wireframes automatically.

2. Live data sensors. Post-launch, analysts pull product analytics and LLM-summarized support tickets to keep the roadmap honest.

3. Domain playbooks. Video, AI interpretation, telemedicine, e-learning — every domain gets a structured kickoff playbook so analysis goes faster without skipping depth.

FAQ

What to Read Next

Ready for an analyst who earns their seat?

Analytics at Fora Soft isn’t a phase, it’s the spine of the project. Our analysts turn messy ideas into shipped software by asking the hard questions early, visualizing everything, and staying in the room through launch. That’s what you’re buying when you hire us — the thinking as much as the coding.

If you’re sizing up a new product, rescuing a stalled one, or weighing vendors, a scoping call with one of our senior analysts is the shortest path from a messy brief to a buildable plan.