AgentPoint+
A widely used WordPress real estate plugin and themes, focusing on the WordPress Gutenberg development project.
Project type
Website, Plugins
Technology
WordPress, Typescript, React,
SCSS, PHP (Laravel)
Year
Early 2024-Present
My Role
Frontend Developer, leading UX and
frontend development on AgentPoint+
Team
Cross-functional team of 8
(design, development, QA)
Overview
Agentpoint is a full-service, professional real estate web design and development firm, now part of Reapit following its acquisition.
With clients worldwide, Agentpoint creates innovative, high-performance websites and lead generation products tailored to the needs of the real estate industry.
At SoftwareSeni, I work as a Front End Developer, contributing to the development of WordPress themes and enhancing the Agentpoint+ Plugin for our clients.
With the introduction of WordPress Gutenberg in 2018, our team has focused on building highly customizable and user-friendly block features specifically designed for real estate applications.
My role involves developing block-based themes that align with this new feature set, enabling users—even those without prior coding experience—to fully customize layouts and blocks to suit their preferences. I have also designed the UX and styled our custom Gutenberg blocks, enabling users to customize them with ease.
Additionally, I helped research and analyze the latest updates from the Gutenberg team to incorporate them into our projects, providing a reference point for starting our work.
Goals
The goals of this project are as follows:
- Create highly customizable, user-friendly custom blocks usable within the client’s chosen theme.
- Develop a block-based WordPress theme that’s easy to use and customize without ongoing developer support.
- Identify opportunities to enhance the platform by leveraging Gutenberg updates.
- Replace outdated legacy widgets and classic themes with custom Gutenberg blocks and block-based themes.
Challenges
Uncertainty
Since Gutenberg is still an actively evolving project, our understanding and resources were limited at times, meaning the nature of our work shifted depending on how the WordPress team updated the framework.
Prioritization
Alongside legacy maintenance work like bug fixes, feature additions, and updates, priorities often shifted. Time constraints made it impossible to convert every existing legacy feature into a Gutenberg block, so we focused on the most critical requirements first.
🕵️♀️ Identifying the problem
With the latest WordPress update promoting the use of Gutenberg blocks, legacy widgets and classic themes have become obsolete in the context of Gutenberg. We need to develop features that fulfill the updated requirements.
⚠️ Highlighted problems
- Customizing and editing widgets in the classic theme is difficult due to the lack of a preview feature.
- Clients, PMs, POs1 and CDOs2 rely heavily on developers to configure widget/custom page arrangements and styling to meet their needs.
- Resource consumption is high due to the way widgets and theme styling are compiled using third-party plugins such as SCSSPHP, which exceeds memory usage limits.
What was my main contribution during the development process?
1
Step 1
Collecting the requirements
My main contribution in this phase was working closely with the product team to understand the overall vision for the new block theme and custom block. I helped break down the design into actionable items, identifying which sections of each page needed to be developed as custom blocks.
I also collaborated with the PM and PO to ensure that we clearly prioritized tasks, setting up sprint planning sessions and creating JIRA tickets. As the developers began their work, I supported them in estimating the effort required for each task by discussing the scope and assigning story points. This helped ensure that everyone was aligned and that the project stayed on track.
2
Step 2
From High-Fidelity Design in Figma to Code
I began by closely reviewing the high-fidelity designs in Figma to ensure all the details were accounted for before translating them into code. I worked with the design team to clarify any questions about layout, spacing, and interactive elements, ensuring the designs aligned with the capabilities of the Gutenberg blocks.
Once everything was clear, I began translating these designs into reusable custom blocks using Gutenberg. This involved setting up the block structure and ensuring the styles from Figma were reflected accurately using CSS and SCSS. I also worked alongside developers to fine-tune functionality and ensure the blocks were fully responsive and user-friendly.
Throughout this process, I made sure the code was maintainable and aligned with best practices, ensuring that the theme could be easily updated or customized in the future without needing significant rework.
3
Step 3
Encouraging Cross-Functional Collaboration for Richer Feedback
I collaborated closely with the team to gather their input on the progress.
Throughout the development process, I made sure to keep everyone informed, walking them through the technical flow and encouraging open discussions. My focus was on creating a space where we could all share ideas, address concerns, and fine-tune the implementation together.
4
Final Step, 4
Conduct thorough testing in collaboration with the QA team
Throughout the development, staging, and production release phases, I collaborated closely with the team, especially the QA team, to conduct thorough testing and ensure the product met the requirements and functioned properly.
Outcomes
What did our team achieve at the end?
Eliminate the pain point of difficulty in adding, editing, or customizing content.
With Gutenberg, users no longer need to rely on developers to set up widgets or manage and style content, as a live preview is available.
The content in the preview follows a what you see is what you get approach, ensuring it is accurately reflected on both the editor and the frontend without any guesswork.
Reduces memory consumption significantly while improving performance.
No longer relies on the SCSS compiler, as it is unnecessary with block themes since we don’t rely much on custom styling.
Iterations
Three themes, 50+ custom blocks, one system that kept maturing.
1
Stage 1 — Establishing
Swell
The first block theme we ever built — with no internal precedent, most of the early work was research: testing WordPress’s block APIs from scratch until an approach held up.
One limitation stood out: WordPress’s core Navigation block couldn’t support the mobile submenu expand/collapse the designer wanted. Rather than drop it, we extended the core block ourselves. The goal throughout — prove a live, WYSIWYG editing experience could replace developer-built widgets.
WordPress’s core Navigation block couldn’t support the mobile submenu expand/collapse
<- A view of the property details page, including the action buttons, image gallery, address, property information, and other details.
14+ blocks
First theme built
Foundation
Swell proved the concept worked — the next theme needed to push further on style and show a wider range of what the system could do.
2
Stage 2 — Scaling
Headland
The second theme — a chance to push further into style, with a matured color palette and clear, labeled variations. Where Swell proved the concept, Headland set out to show what WordPress could really do design-wise: more polished, with real variety on offer.
One addition stood out: extending the core Group block to let header elements change color on scroll — a setting that didn’t exist by default. Along with more blocks overall, Headland’s real growth was in variation, not just volume.
10+ blocks
Matured color palette
Extend Blocks
3
Stage 3 — Evolving
Evolve
The most mature and lowest-maintenance of the three — fast to onboard, lighter to run.
<- A call to action section that displays a flexibility of showing the icon with label and description
A flexible view of the property details page, with a new pattern to choose from.
10+ blocks
Flexible
40+ blocks and 3 themes later: one system, matured through three real production constraints.
Learnings
What I have learned from this project!
This project required me to design solutions while diving deeper into research on the WordPress Gutenberg project. It pushed me to address complex challenges by accounting for different levels of user expertise and developing solutions tailored to their needs.
Product Owner:
Faiz…. 🤔
The current version of WordPress navigation block doesn’t support the feature to enable the arrow expand/collapse submenu on mobile layout by default.
Due to this limitation, would it possible to use the existing WordPress navigation block and adjust it from our end instead?
Me:
After some digging, it seems we can “extend” the existing WordPress core block with new setting based on this article https://developer.wordpress.org/news/2024/08/how-to-extend-a-wordpress-block/
Let me check and try extend the block!
Even though I’m just the developer, watching the PM manage our project has helped me think more organized. I have to document issues, blockers, limitations, and solutions in a way that’s easy to read, whether it’s in a doc or a ticket. It’s definitely helped me get better at staying on top of things.
This project helped me improve how I communicate with the team about blockers. I had productive discussions with the team to figure out solutions, possible blockers, limitations, and what we discovered about the WordPress Gutenberg project.
GMOOC (Gamified Massive Open Courses)
An open online course platform using a gamification approach. Gamification provides an opportunity for the learner to master the available quests interestingly and interactively.
FUKUO (Tumblr Theme Development & Web Design)
FUKUO started in 2012 as a personal project;
a Tumblr blog where a self-taught developer shared free themes with anyone who wanted them.