Last year I built an app entirely through ServiceNow’s Build Agent; this year I rebuilt it using the latest SDK and Cursor as my AI-driven workflow partner.
The following is related to the lastest release of the ServiceNow SDK and the Build anywhere, run on ServiceNow product launch.
Revisiting the challenge
Last year, during the #BuildWithBuildAgent challenge, ImpactHub started as a public-facing app for NGOs to collect and manage social project submissions. The app included a public form, a backend table, approval workflows, dashboards, and role-based access for applicants and reviewers.
This time, the goal was not to recreate the app line by line. The goal was to revisit the same idea with a different workflow and compare how the experience changed when using the latest ServiceNow SDK together with Cursor.
Why use the same app idea
ImpactHub still felt like the right test case because it combines several patterns that are common in real projects:
- A public form for project submissions with media uploads
- A backend table to store project applications
- An approval workflow with status tracking
- Role-based access for applicants and reviewers
- Dashboards with counts, funding totals, and status breakdowns
Another important part of the comparison is that the original Build Agent challenge allowed only 10 prompts. That meant every prompt had to do real work. To keep the comparison fair, the rebuild with Cursor also stayed under a soft limit of fewer than 10 main prompts.
From Build Agent prompt to SDK and Cursor
Here is the original Build Agent prompt, shortened for clarity:
Create a public-facing application for an NGO to track social project applications.
Requirements:
- Public applicant access without ServiceNow login
- Mobile-friendly submission form with media uploads
- Internal project team can review, request info, approve or reject
- Project Application table with fields for title, description, funding,
impact, location, category, applicant contact, media attachments, status,
notes, approval date, and approving user
- Public and internal dashboard for counts, funding totals, and status
- Security so public users can only see their own submissionsThat single prompt produced a complete app structure. It was impressive, but it also felt like a black box.
This time, the workflow shifted. Instead of relying on Build Agent to do everything inside the platform, the app was defined locally with the ServiceNow SDK while Cursor helped with drafting and refining the pieces. All details of the Build Agent Challenge including the prompt can be found here: ImpactHub
SDK setup
The setup started with a local project and a clean environment:
node -v
npm -v
npm install --global @Servicenow/sdk
Then the project was initialized:
mkdir impacthub-sdk
cd impacthub-sdk
npx @Servicenow/sdk auth --add dev-instance
npx @Servicenow/sdk init
Rebuilding ImpactHub with Cursor
The rebuild did not start with one giant prompt. Cursor worked better as a partner when the work was broken into smaller, scoped requests.
A starting prompt looked like this:
Using the ServiceNow SDK, define the core ImpactHub application structure.
The app should track social project applications for an NGO.
Key entities:
- Project Application table with fields for title, description,
requested funding amount, expected impact, location, category,
applicant contact information, media attachments, status, reviewer notes,
approval date, and approving user.
Status values: Draft, Submitted, In Review, Info Requested, Approved, Rejected.
Suggest how to structure this as Fluent-style SDK artifacts.
From there, the next prompts focused on one layer at a time: security, workflow, dashboards, and roles.
Keeping the work in smaller chunks made the output easier to review and easier to adapt.
A follow-up prompt looked like this:
Suggest a security model for the ImpactHub app:
- Public applicants can only create and view their own submissions
- Project team members can read and edit all applications
- Use scoped roles and access controls appropriate for ServiceNow
How to try the same exercise
If you want to repeat the same experiment on a Personal Developer Instance, the path is simple:
- Check Node.js and npm.
- Install the ServiceNow SDK.
- Initialize a new local project.
- Open it in Cursor.
- Use fewer than 10 main prompts to scaffold the core table, security model, workflow, and dashboard ideas.
- Build and validate the app.
npx @Servicenow/sdk build
npx @Servicenow/sdk install --profile dev-instance
What changed this time
- Fewer, better prompts matter. The original 10-prompt limit forced careful prompt writing, and the same discipline helped again with Cursor.
- The SDK adds visibility. Instead of seeing only the final result, the app becomes a set of local files and artifacts that can be reviewed and improved.
- I also created ATFs this time. In the original Build Agent challenge, I did not set up automated tests. This time, I used the workflow to think about testing too, which made the app feel more complete and more repeatable.
- Cursor works best in focused steps. Asking it for one artifact or one problem at a time produced better results than trying to generate the whole app in one shot.
- Human review still matters. The tools can speed up drafting, but the quality still depends on understanding the platform and knowing what good design looks like.
Applicant UI
The color and tone were picked by the AI to match the intent, and I have to admit they look very, very different. Cursor used a completely different approach: it split the submission into two pages and also created a dashboard for the user. In my opinion, this version feels more user‑friendly, but the initial arrangement of the controls was a mess.
Cursor:
Build Agent:
Team UI
The interfaces have similar content, but they look very different again. Build Agent went with a more compact layout, while Cursor created a dashboard to control your list of project submissions. Which one do you prefer?
Cursor:
Build Agent:
Closing thought
Rebuilding ImpactHub with the latest ServiceNow SDK and Cursor changed the value of the exercise. The first time, the interesting part was watching an app appear from a natural-language prompt under a strict 10-prompt limit. This time, the interesting part was seeing the same idea become a more transparent, iterative, and reusable workflow.
I also only scratched the surface with Cursor. There are already more possibilities around it, including Figma-related plugins and integrations in the Cursor ecosystem, which opens up interesting directions beyond what I explored here. Probably you tried it already, let me know in the comments.
If you joined the Build Agent challenge before, it is worth revisiting your app idea. Rebuild it with the SDK, bring Cursor into the process, keep the prompt count low, and compare what changed.
