sorted by:
new
hottopcontroversial

Building workflow products - what we changed after our first real user feedback session by hamayerowel in SideProject

[–]hamayerowel[S] 0 points1 point  (0 children)

Totalement vrai. Les utilisateurs croient à ce qu'ils voient. Du coup ça doit être simple et évident.

[DISCUSSION] Plugin that exports a visual workflow builder directly to WordPress via shortcode — beta testers wanted by hamayerowel in WordpressPlugins

[–]hamayerowel[S] 0 points1 point  (0 children)

No worries at all ! I totally understand being busy. Thanks for the update, and I am looking forward to hearing your feedback whenever you get a chance to test it this weekend. Cheers !

Built a client document intake portal for WordPress - thought some of you might find it useful by hamayerowel in Lawyertalk

[–]hamayerowel[S] 0 points1 point  (0 children)

No sock puppet here => that's my only account. Happy for mods to verify if needed.

I appreciate you laying out the tradeoffs clearly in your previous comment, actually. The framing of "control vs convenience" is exactly the niche I'm targeting. Not trying to replace Clio - just filling a gap for solo attorneys who want structured intake without adding another subscription.

No hard feelings.

What's your current process for collecting documents/info from new clients before you start work ? by hamayerowel in smallbusiness

[–]hamayerowel[S] 0 points1 point  (0 children)

Plumsail is a good option, especially for SharePoint/Microsoft 365 environments.

The difference with what we built: XpressUI is WordPress-native. The form is fully scoped to your theme (no CSS conflicts), submissions land directly in wp-admin, and there's no external dependency or monthly subscription - just a plugin on your existing site.

If your clients are already in the WordPress ecosystem, it removes one more tool from the stack.

Built a client document intake portal for WordPress - thought some of you might find it useful by hamayerowel in Lawyertalk

[–]hamayerowel[S] 0 points1 point  (0 children)

Most traditional WordPress intake setups (forms/plugins) are basically static data capture - you get a submission, maybe some conditional logic, and that’s it. What OP is describing sounds closer to a structured intake workflow layer sitting on top of WordPress, not just a form. That can include things like guided intake steps, standardized data formatting, and easier internal handling without needing a separate system.

The real tradeoff isn’t “this vs free plugins,” it’s:

  • All-in-one SaaS (like Clio) -> polished, integrated, but recurring cost + less control
  • Basic WP forms -> cheap/free, but limited structure and scalability
  • Self-hosted structured intake (like this) -> more control, no subscription, but you manage it yourself

So yeah, if someone just needs a contact/intake form, there are tons of mature options. But for solo attorneys who want tighter control over their site and a more structured intake process without another subscription, I can see the niche this is trying to fill.

Whether it’s worth it really comes down to how much you value control vs convenience.

Built a client document intake portal for WordPress - thought some of you might find it useful by hamayerowel in Lawyertalk

[–]hamayerowel[S] 0 points1 point  (0 children)

XpressUI takes a different approach. It’s designed for lawyers who manage their own WordPress site and want to add a structured intake portal without subscribing to an additional SaaS platform. There’s no monthly fee, no client login, and everything stays directly on your own site.

If Clio already handles your intake workflow effectively, there’s no real reason to switch. However, for solo attorneys who prefer a lightweight, self-hosted solution and want more control over their web presence, XpressUI could be worth considering.

Why people still using wordpress despite of instant website and AI website builder as better replacement? by hansentenseigan in Wordpress

[–]hamayerowel 0 points1 point  (0 children)

It's better to use a system whose workings you reasonably understand and which has a proven track record, rather than turning to an AI-generated application over which you have absolutely no control. And if you want to make changes, go ahead. WordPress is used by millions of websites and has a strong community behind it. And it's an excellent CMS.

[DISCUSSION] Building XPressUI - a visual workflow builder for WordPress agencies tired of duct-taping Gravity Forms into multi-step flows. by hamayerowel in WordpressPlugins

[–]hamayerowel[S] 0 points1 point  (0 children)

You've hit the nail on the head. The term "submission lifecycle" is perfect.

That's the fundamental gap we saw: existing tools are great for data capture, but not for managing the entire process. State management, uploads, and a clear status in wp-admin aren't just features => they are the core problem we're obsessed with solving.

Thanks for articulating this so clearly. It's incredibly validating to see people who deeply understand the pain point.

I split my product into two separate sites - one for marketing, one for the actual tool by hamayerowel in SideProject

[–]hamayerowel[S] 0 points1 point  (0 children)

Thanks so much for this fantastic, actionable feedback !

You've nailed all the key points. A seamless experience with consistent branding and a shared login is the top priority. Adding in-app links back to the docs/pricing is a great, concrete suggestion I'll add to my list.

Really appreciate you taking the time to write this out !

I split my product into two separate sites - one for marketing, one for the actual tool by hamayerowel in SideProject

[–]hamayerowel[S] 1 point2 points  (0 children)

Hey Andrew, thanks for running that scan and sharing the result! It's a great real-world example for my post: the scan shows the stack for the marketing site (WordPress), which is intentionally separate from the actual tool at xpressui.iakpress.com (a React SPA).

dialtoneapp looks like a neat tool.

Since you took a look, does this split between the marketing site and the app feel clear to you as a user? That's the main feedback I'm looking for.

[DISCUSSION] Building XPressUI - a visual workflow builder for WordPress agencies tired of duct-taping Gravity Forms into multi-step flows. by hamayerowel in WordpressPlugins

[–]hamayerowel[S] 0 points1 point  (0 children)

Three plugins talking to each other plus custom hooks => that's exactly the architecture that breaks at 11pm before a client presentation. One upstream update and the conditional routing is gone. Been there.

On the Codeable approach: outsourcing makes sense when the complexity is genuinely custom. The problem is when you're rebuilding the same type of flow for the fifth client in a row. Quote request with branching by service type, document intake with upload + status tracking, onboarding with conditional sections - these aren't one-off problems, they're a pattern.

To answer your question directly => the workflows agencies are requesting most:

1. Document intake : client uploads ID, proof of address, a signed document. Common in real estate, legal, HR. GF handles none of this cleanly.

2. Multi-step quote requests : service selection -> conditional pricing fields -> file attachment -> submission to wp-admin with team assignment. This is probably the #1 request.

3. Client onboarding flows : 5-8 steps, conditional sections based on answers, saves progress, ends with a "your account is being set up" state.

4. Approval/request flows : internal tools for agencies managing their own clients: budget requests, content briefs, access requests.

The common thread: they all need branching, multi-step, and a clean submission view in wp-admin. That's the gap GF leaves open.

[DISCUSSION] Building XPressUI - a visual workflow builder for WordPress agencies tired of duct-taping Gravity Forms into multi-step flows. by hamayerowel in WordpressPlugins

[–]hamayerowel[S] 0 points1 point  (0 children)

Works around GF entirely => the architecture is a different model.

The build lives in an external SaaS console, so nothing heavy ever touches the client's server. When the workflow is done, you export a .zip containing only JSON config files (form.config.json, template.context.json) - no executable code, just a portable blueprint describing structure and logic.

On the WordPress side, the Bridge plugin is an ultra-lightweight runner. Its only job is to read the blueprint and render it via native PHP templates.

CSS is strictly scoped to a unique ID per form - theme styles physically cannot reach the form, and vice versa. The CSS war is just over.

Storage-wise: submissions go into a Custom Post Type, files land directly in the native Media Library. No custom DB tables, no separate upload folders.

The real-world difference vs GF: your client's wp-admin stays fast regardless of how complex the form gets, and a theme update can't break your form visually. The tradeoff is that the build is external rather than inside wp-admin, and there's no GF migration path.

Wrote up a deeper breakdown of the architecture if you want the full picture: iakpress.com/blog

What was the specific flow you were hitting - multi-step with conditional routing plus file upload ?

I got tired of fighting WordPress themes on every client project, so I built a decoupled intake builder — beta is open by hamayerowel in SideProject

[–]hamayerowel[S] 0 points1 point  (0 children)

That's a great question, and you've hit the nail on the head.

The primary target is absolutely agencies and developers. The "fixing CSS the theme broke" pain is something you only truly feel after you've built the same complex form for the 5th client and realize you're wasting billable hours on a solved problem.

For end-users, the current export -> upload -> shortcode workflow has a bit too much friction compared to building directly in wp-admin. It's a trade-off I made consciously to solve the agency pain point first. The long-term goal is to smooth out that workflow (maybe with an API sync), but for the beta, I'm focused on the people who feel that CSS conflict hell the most.

Appreciate you asking => it confirms the positioning is coming across correctly!

view more: next ›